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(57) Abstract: The invention includes a system and method for providing a process-container platform (302) which includes a sys- 
tem for process automation and collaboration. The system includes process-containers that are mobile, self-contained, asynchronous, 
executable, visualizeable agents that include presentation information, logic, and data. Also included a peers that run on host net- 
worked devices (300) such as personal computers in a local area network and are operable to display, transmit, interact with, and 
receive the processe-containers (304). In addition, both on and off-line, peers are operable to execute the logic of the process-con- 
tainers (304) and provide the process-containers access to data and applications (326) also stored or running on the local host. The 
process-containers (304) are operable to move between the peers to execute the process described in the logic of the process-con- 
tainer. The process-container is further operable to carry its data in the form of documents, including multi-media documents, as it 
moves between peers. ^ 
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FIELD OF THE INVENTION 

The present invention relates to methods and apparatus for process automation and 
collaboration. More specifically, the present invention relates to applications, software 
development platforms, application programming interfaoes, and software execution platforms for 
mobile agent-based process automation and collaboration. 



BACKGROUND OF THE INVENTION 

Conventional automation systems are unable to meet the diverse needs of enterprise- 
25 wide business processes that frequently span multiple organizations. Further, most business 
processes are dynamic, ad hoc, change and grow in unpredictable ways, long njnning, not weD 
understood by any single participant much less all participants, often require some degree of 
collaboration between participants, and frequently require a substantial amount of exception 
processing. In an era in which large corporations readily spend millions of dollars annually on 
30 software, the lack of any clearly dominant commercially available application, or even a platform 
for developing such applications, illustrates that the existing solutions for automating enterprise- 
wide business processes fail short of solving the inherent challenges described above. 

Once the infrastructure of the Internet was In place sufficiently to facQitate efficient 
communication via email and the World Wide Web (Web), there were several unsuccessful 
35 attempts to create systems to help automate the elaborate interactions between companies 

beyond the static and Inflexible transactions of early closed systems such as the Electronic Data 
Interchange (EDI) system or unscalable workflow applications. Some of the first Intemet-based 
systems to emerge included Enterprise Application Integration (EAl), Business-to-Business 
Integration (B2Bi). and wel>-based workflow. These systems suffered from a number of 
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drawbacks Including that in using these systems it was difficult to implement and maintain 
processes; these systems were unable to handle unpredictable or ad hoc processes; these 
systems did not work with diverse content formats and standards; and they were largely focused 
on machine-to-machine interactions. The generation of systems that followed next included 
5 publishing and portal systems. These systems suffered from some of the drawbacks of the prior 
generation and they included some of their own [imitations. These systems could not handle 
exceptions or ad hoc processes; they generally did not support collaborative Interacttons 
between participants; they typteaity relied on a single-hub model; and they did not provide 
support for offline and incremental work by users of the systems. 

10 Commerce applications came next following the portal-based systems. IHowever, these 

systems were largely focused on merely enabling sales transactions and did not address the 
much broader and richer set of interactions engaged in by businesses and other enterprise-sized 
entities, particularly multi-national corporations and govemments. in addition, using these 
systems it was difficult to extend the process beyond the transaction or deal with exceptkms. 

1 5 These applications did not provide any facSities for coDaboration and they were unable to handle 
diverse content formats and standards. 

|j}oking at the conventional systems of the past it becomes clear that where the primary 
focus was on process automation (ERP, EIA/B2BI, workflow systems) there was a significant 
shortfall of collaborative interaction. In addition, these systems were complex and costly to 

20 implement; they were inflexible and non-adaptive; and they did not readily support inter- 
enterprise processes. Where the primary focus was on collaborative interactton (email 
exchanges, groupware, workspace) there was a significant shortfall process automation. In 
addition to not providing any real process support, these systems did not provide system 
architectures that allowed sharing of processes or even selective Information across 

25 organizations. Further, these collaborative systems severely lacked architectural-level support 
for Integration with transactional systems. 

It would be advantageous to provide a system that overcomes the limitations and 
drav/backs of the prior art discussed above. What is needed are systems and methods that can 
provide a metaphor for Integrating human and system interactions; support structured processes 

30 while enabling ad-hoc collaboration; many rich multi-media content and integration to 

transactional systems; eliminate hub-centric portal-based systems; support true cross-enterprise 
collaboration with a flexible network of owners and participants. What is further needed are 
systems based on an architecture that provides both process automation and collaboration wtiile 
at the same time addressing processes that are dynamic, ad hoc. unpredictable, long running, 

35 not well understood by the participants, and require exception processing. 
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SUMMARY OF THE INVENTION 

To overcome the shortcomings Inherent in the prior art, embodiments of the present 
5 Invention provide a system and method that enables both process automation and collaboration. 
The present invention overcomes the drawbacks of the prior art by providing a scaleable. flexible, 
and adaptable architecture that both albws the automating of ad hoc processes and facilitates 
collaboration. 

According to some embodiments of the Invention, a system for automating a process 

10 includes one or more process-containers that are mobile, self-contained, asynchronous, 

executable, visualizeable agents that include presentation information, logic, and data. Such a 
system also Includes one or more peers that run on host networked devices such as personal 
computers in a local area network and are operable to display, transmit, interact with, and 
receive the process-containers. In addition, peers are operable to execute the logic of the 

1 5 process-containers and provide the process-containers access to data and applicatibns also 
stored or running on the host. In some embodiments the process-containers move between the 
peers to execute the process described In the logic of the process-container. The process- 
container is operable to carry its data In the form of documents, including multi-media 
documents, as It moves between peers. In some embodiments the process-containers are 

20 presented to users via the peers to allow the users to access the process-container's data and 
interact with the process-container's logic, in some embodiments, the host computer executing a 
process-container docked in a peer need not be coupled to a network because the process- 
container Is self-contained and does not rely resources that are not immediately available to it. 
With these and other advantages and features of the Invention that will become 

26 hereinafter apparent, the nature of the invention may be more clearly understood by reference to 
the following detailed description of the Invention, the appended claims and to the several 
drawings attached herein. 

30 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 1s a block diagram illustrating an example system according to some 
embodiments of the present invention. 

FIG. 2 Is a block diagram Illustrating a second example system according to some 
35 embodiments of the present Invention. 

FIG. 3 is a block diagram illustrating an example of an enabled host client or server as 
depicted in FIGs. 1 and 2 according to some embodiments of the present invention. 

FIG. 4 Is a block diagram illustrating an example of an host server according to some 
embodiments of the present Invention. 
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FIG. 5 is a block diagram illustrating an example of an unenabled client coupled to a host 
server according to some embodiments of the present invention. 

FIG. 6 is a block diagram illustrating an example of an enabled client in communication 
witii a host server according to some embodiments of the present invention. 
5 FIG. 7 ts a block diagram illustrating an example structure of a process-container engine 

for use in some embodiments of the present invention. 

FIG. 8 is a block diagram illustrating an example structure of a support layer of an 
example process-container engine for use In some embodiments of the present Invention. 

FIG. 9 is a block diagram illustrating an example structure of a runtime layer of an 
10 example process-container engine for use in some embodiments of the present invention. 

FIG. 10 is a block diagram illustrating an example structure of a process-container 
session subsystem within a njntime layer of an example process-container engine for use in 
some embodiments of the present Invention. 

FIG. 11 is a bk)ck diagram illustrating an example stmcture of a process-container 
1 5 message internee for use in some embodiments of the present inventkm. 

FIG. 12 is a block diagram illustrating an example MIME form of a process-container for 
use in some embodiments of the present invention. 

FIG. 13 is a block diagram illustrating an example structure of a process-container 
service interface for use in some embodiments of the present invention. 
20 FIG. 1 4 is a block diagram Illustrating an example stmcture of a verb protocol subsystem 

for use in some embodiments of the present inventkm. 

FIG. 15 is a block diagram illustrating an example stmcture of core model interfaces 
within a core layer of an exannpie process-container engine for use in some embodiments of the 
present invention. 

25 FIG. 16 is a block diagram illustrating an example structure of a core subtype for use in 

' some embodiments of the present invention. 

FIG. 17 is a block diagram illustrating an example stmcture of DOM-Java mapping in a 
core model for use in some embodiments of the present inventton. 

FIG. 18 is a block diagram illustrating an example stmcture of a core model for use in 
30 some embodiments of the present invention. 

FIG. 19 is a block diagram illustrating an example structure of a process-container within 
an example process-container engine for use In some embodiments of the present invention. 

FIG. 20 Is a state-diagram illustrating an example of process-container mntlme lifecycle 
modes as used in some embodiments of the present inventton. 
35 FIG. 21 is a block diagram illustrating an example stmcture of a process-container binder 

for use in some embodiments of the present invention. 

FIG. 22 is a block diagram illustrating an example structure of an execution layer of an 
example process-container engine for use in some embodiments of the present invention. 
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FIG. 23 is a block diagram iliusfrating an example sfructure of an execution layer 
executing a process-container In some embodiments of the present Invention. 

FIG. 24 is a block diagram Illustrating an example structure of a component interface 
hierardiy for use in some embodiments of the present invention. 
5 FIG. 25 is a block diagram illustrating an example structure of a component subtypes 

Interface hierarchy for use in some embodiments of the present invention. 

FIG. 26 is a block diagram illusbating an example structure of a page context for use in 
some embodiments of the present Invention. 

FIG. 27 Is a state-diagram Illustrating an example of page context IHecycle modes as 
10 used in some embodiments of the present invention. 

FIG. 28 is a block diagram illustrating an example structure of a page protocol for use in 
some embodiments of the present invention. 

FIG. 29 is a block diagram iilustrating an example structure of a page initialization 
process for use in some embodiments of the present invention. 
15 FIG. 30 is a bUxk diagram illustrating an example stnicture of a scheduler for use In 

some embodiments of the present Invention. 

FIG. 31 is a block diagram illustrating an example structure of an annotation execution 
for use In some embodiments of the present invention. 

FIG. 32 is a block diagram illustrating an example structure of a browser model for use in 
20 some embodiments of the present invention. 

FIG. 33 is a block diagram illustrating an example structure of a page building process 
for use in some embodiments of ttie present invention. 

FIG. 34 is a bkxk diagram Illustrating an example structure of an event flow process for 
use in some embodiments of the present invention. 
25 FIG. 35 is a scope diagram Illustrating an example structure of static scope lor use in 

some embodiments of the present invention. 

FIG. 36 is a scope diagram illustrating an example structure of dynamic scope for use in 
some embodiments of the present invention. 

FIG. 37 is a block diagram illustirating an example structure of a source to sink event ftow 
30 for use in some embodiments of the present invention. 

FIG. 38 is a block diagram illustrating an example structure of a scope level broadcast 
for use in some embodiments of tiie present invention. 

FIG. 39 is a block diagram illustrating an example structure of an event encapsulation for 
use In some embodiments of tiie present Invention. 
35 FIG. 40 is a block diagram illustrating an example structure using publish and subscribe 

parameters to cross scope boundaries for use In some embodiments of tiie present invention. 

FIG. 41 Is a block diagram illustrating an example structure using publish and subscribe 
parameters to publish articles for use in some embodiments of ttie present invention. 
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FIG. 42 Is a block diagram illustrating an example structure of varialrfe scoping for use m 
some embodiments of the present Invention. 

FIG, 43 Is a block diagram Illustrating an example structure of a XCL transform for use in 
some embodiments of the present Invention. 
5 FIG. 44 Is a block diagram illustrating an example structure of a XCL collection for use in 

some embodiments of the present mvenfion. 

FIG. 45 is a block diagram illustrating an example structure of an extensions architecture 
for use In some embodiments of the present invention. 

FIG. 46 is a block diagram Illustrating an example structure of a processing model for 
10 use in some embodiments of the present Inventton. 

FIG. 47 Is a block diagram illustrating an example structure to support execution and 
back-end processing of Process-containers in some embodiments of the present Invention. 

1 5 DETAILED DESCRIPTiON OF THE INVENTION 

Applicants have recognized that a need exists for systems and methods that provide 
both process automation and collaboration. The present invention provides a novel approach to 
engineering software automation and collaboration solutions. This approach is based upon a 

20 novel set of design principles that were derived via an analysis of the salient tenets of 

automation. Some of these tenets include the Idea that language and its use provide a preferred 
model for automation and the Idea that good automation preferably maximizes both of the 
sometimes contradictory elements of freedom and control in the use of software. 

Language, both spoken and written, In the way It efRcientiy and naturally facilitates and 

25 thus, automates communication , provides an example of how highly optimal forms of automation 
may be implemented by providing systems that are adapted to and consistent with the way 
people naturally do things. In terms of computer software applications, email may be thought of 
a system for automating conversatfon and ttie word processor may be thought of as a system for 
automating written language. The ^ct that email and word processors are by far the most used 

30 software applications validates the Idea that automation Implemented using software should 
enable the natural behaviors of people by aligning itself with tiie characteristics of language. 

Maximizing botii freedom and control In a software application can be difficult because 
asserting strong conti-ols may overly restrict users' freedom while allowing too much freedom 
may Interfere with mechanisms for maintaining control. Freedom allows users, for example, to 

35 perform the functions provided by the software In a manner that makes sense to them and allows 
Uiem to be creative or have ttieir specific needs met. Control allows users to be confident that 
software functions are perfonned, for example, wittiout corrupting data, according to a defined 
schedule, or In a secure environment. Optimizing tiie balance between freedom and control so 
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as to maximize both is cleariy the preferred compromise that most nearly matches the natural 
tendencies of most users. 

If the tenets of automation discussed above are accepted and one looks objectively at 
how "state of the art" automation relates or fails to relate to these tenants, a number of software 
5 design principles can be derived. These principles include the ideas that (1 ) conventional 

database transactions are oriented to system transactions and not toward people interactions; (2) 
enhancements not perceptible at the user interface do not compel adoption; (3) as humanity is 
preferably and naturally decentralized so should application platforms be; (4) applications that 
cause users to perform operations solely to accommodate the application Instead of tasics 

1 0 directly related to completing substantive objectives fail to relate to how people naturally to 
things; and (5) object oriented application development prindpies remain relevant and are 
applicable to Internet applications. 

Database transactions are for systems not for people. The first design principle is that 
database transactions are not part of the way that people work. However, looking at most of the 

1 5 presently commerdaliy available applications, one vi/ould think people enjoy data entry and 
formulating queries. Transactions were designed to assist the database In provkJIng a simple 
model for concurrency and robustness. However, this simple model imposes some onerous 
burdens on users: (1) users are forced to complete their work in one session; (2) users are 
unable to make Intermediate results of their work visible to others; and (3) the system is unable 

20 to make intermediate results available for external processing. These restrictions on user 

freedom have the consequences that, among other things, long running tasks are not suitable to 
such systems; users are not able to collaborate without "committing'' to the global state of the 
database; and opportunities for concurrent processing are squandered. 

The "desktop," a metaphorical computer interface that naturally allows users to interact 

25 with multiple applications and/or instances of applications in the same way people use multiple 
books, papers, charts, and images on the working surface of an actual desk, is the dominant 
Interface for the majority of modem computer operating systems. From the perspective of 
creating an application that is compelling to users, the preferred area to add value Is predsely 
u/here the user will experience the value add. Thus, application platforms that do not add value 

30 at that level, will have great difficulty truly captivating users. 

Centralization restricts scalability, creates bottlenecks, and does not allow use of 
distributed processing power. The Web was not intended to centralize, but to decentralize. An 
application platform that supports only centralized processes will have great difficulty scaling to 
the size of the Web, nor will It fit the temperament of the WEB. 

35 Applications should not own users, users shouM own fine applications. A good 

application platfonm should assist the user in building applications that suit the user, not the 
applicatton. Users should be given the control to automate applications when and how they best 
serve the processes that people actually undertake. Processes are not In any one application, 
they span multiple applications. 
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Objects and object-orfented design'can be applied to and add value to XML, HTML, and 
other Web languages. The same concepts of problem subdivision and reusability are even more 
applicable in modem WEB applications. 



5 A. DEFINITIONS 

Throughout the description that follows and unless othenvise defined, the following terms 
will refer to the meanings provided in this section. These tenns are provided to clarify the 
language selected to describe the embodiments of the invention both in the specification and in 
the appended daims. Many additional terms are defined throughout the specification. 
10 The term "document" shall refer to any form of electronic data such as, for example, a 

database, spreadsheet, illustration, text file, movie, photograph, or audio recording that contains 
infomiation. 

The term "Process-container" shall refer to a mobile, self-contained, asynchronous, 
executable, visualizeable agent that has advanced presentation, logic, and data layers that may 

15 be embodied using extensible mark-up language (XML). Web. and Java* standards. Note that in 
the Provisional Application from which the present application claims priority, a Process- 
container was refen-ed to as a "Sltelet™." 

The term "client device" shall refer to a computing device operating generally under user 
control. Client devices will typically be personal computers but may include may other 

20 networkable and/or wireless devices. 

The term "server device" shall refer to a computing device operating generally under 
program control. Server devices will typically be server computers running one or more 
enterprise applications including database management systems. Server devices may also 
include may other networkable and/or wireless devices. 

25 The term "input device" shall refer to a device that is used to receive an input. An Input 

device may communicate with or be part of another device {e.g. a personal computer, a personal 
digital assistant, an end-user device, a server device). Possible input devices include: a bar- 
code scanner, a magnetto stripe reader, a computer keyboard, a point-of-sale temilnal keypad, a 
touch screen, a microphone, an infrared sensor, a sonar-based distance measurement device, a 

30 computer port, a video camera, a digital camera, a GPS receiver, a radio frequency identification 
(RFID) receiver, a RF receiver, a thenmometer, and a weight sensor. 

The term "output device" shall refer to a device that is used to output Information. An 
output device may communicate with or be part of another device (e.g. a personal computer, a 
personal digital assistant an end-user device, a server device). Possible output devices inctude: 

35 a cathode ray tube (CRT) monitor, Hqukl crystal display (LCD) screen, light emitting diode (LED) 
screen, a printer, an audio speaker, an infra-red transmitter, and a radio transmitter. 
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B. SYSTEM 

Referring now to FIG. 1, a system 100 according to some embodiments of the present 
invention includes one or more server devices 106, 108 that are In one or two-vi/ay 
communication vAih each other and/or one or more of each of a plurality of dient devices 102, 
5 104. Communication between the server devices 106, 108 and the client devices 102, 104 may 
be direct and/or via a network such as the IntemeL 

Each of the server devices 106, 108 and the dienl devices 102, 104 may comprise 
computers, such as those based on the Intef Pentium® processor, that are adapted to 
communicate with each other. Any number of sen/er devices 106, 108 and client devices 102, 

10 1 04 may be in communication with each other. The server devices 106, 108 and the client 

devices 102, 104 may each be physically proximate to each other or geographically remote fix)m 
each other. These devices may each include Input devices and output devices. 

As Indicated above, communication between the sen/er devices 106, 108 and the client 
devices 102, 104 may be direct or indirect, such as over an Internet Protocol (IP) network such 

15 as the Internet, an Intranet, or an extranet running on one or more remote servers or over an on- 
line data network including commercial on-line service providers, bulletin board systems, routers, 
gateways, and the like. In yet other embodiments, the devices may communicate over local area 
networks including Ethernet, Token Ring, and the like, radio frequency communications, infrared 
communications, microwave communications, cable television systems, satellite links, Wide Area 

20 Networks (WAN), Asynchronous Transfer Mode (ATM) networks, Public Switched Telephone 
Network (PSTN), other wireless networks, and the like. 

Those skilled In the art will understand that devices In communication with each other 
need not be continually transmitting to each other. On the contrary, such devices need only 
transmit to each other as necessary, and may actually refrain from exchanging data most of the 

25 time. For example, a device in communication with another device via the Internet may not 
transmit data to the other device for weeks at a time. Additionally, devices 102, 104, 106, 108 
may disconnect from each other and the network and then later reconnect 

The server devices 106. 108 and the client devices 102. 104 may function as "web 
servers" that generate web pages which are documents stored on Internet-connected computers 

30 accessible via the World Wide Web using protocols such as. e.g., the hyper-text transfer protocol 
("HTTP"). Such documents typically Include a hyper-text markup language ("HTML") file, 
associated graphics, and script files. A web server may allow communication with the server 
devices 106, 108 and the client devices 102. 104 In a manner known in the art. The sen/er 
devices 106, 108 and the client devices 102, 104 may use a web browser, such as 

35 NAVIGATOR* published by NETSCAPE* for accessing HTML fbrnis generated or maintained by 
or on behalf of the sender devices 106, 108 and the client devices 102. 104. 

As indicated above, any or all of the sen/er devices 106. 108 and the client devtees 1 02, 
104 may Include, e.g., processor based cash registers, telephones, Interactive voice response 
(IVR) systems such as the ML400-IVR designed by MISSING LINK INTERACTIVE VOICE 
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RESPONSE SYSTEMS, cellular phones, vending machines, pagers, personal computers, 
portable types of computers, such as a laptop computer, a wearable computer, a palm-top 
computer, a hand-held computer, and/or a Personal Digital Assistant ("PDA"). 

In some embodiments of the invention the server devices 106, 108 may be operated 
5 under the control of one or more users. Further, in some embodiments, the client devices 1 02, 
104 may operate automatically, under program control, and/or independent of users. Although 
not pictured, the server devices 106, 108 and the client devices 102, 104 may also be in 
communication with one or more institutions to effect transactions and may do so directly or via a 
secure network such as the Fedwire network maintained by the United States Federal Reserve 
10 System, the Automated Clearing House ("ACH") Network, the Clearing House Interbank 
Payments System ("CHIPS"), or the like. 



C. DEVICES 

The devices 102, 104, 106, 108 are operative to manage the system and execute 

1 5 various methods via the execution of the software of the present Inventton. The devices may be 
Implemented as one or more system controllers, one or more dedicated hardware circuits, one or 
more appropriately programmed general purpose computers, or any other similar electronic, 
mechanical, electro-mechanical, and/or human operated device. 

The devices comprise a processor, such as one or more Intel® Pentium® processors. 

20 The processor nriay include or be coupled to one or more clocks, which may be useful for 
joumaling and determining infonnatfon relating to synchronization, and one or more 
communication ports through which the processor communicates with other devk:es. The 
processor is also in communication with a data storage device. The data storage devk» includes 
an appropriate combination of magnetic, optica! and/or semiconductor memory, and may Include, 

25 for example, additional processors, communication ports, Random Access Memory ("RAM"), 
Read-Only Memory ("ROM"), a compact disc and/or a hard disk. The processor and the storage 
device may each be, for example: (I) located entirely vtfithin a single computer or other computing 
device; or (ti) connected to each other by a remote communication medium, such as a serial port 
cable, telephone line, radio frequency transceiver, or the like. In some embodiments for 

30 example, the devices may comprise one or more computers (or processors) that are connected 
to a remote server computer operative to execute programs and store data, where the data 
storage device is comprised of the combination of the remote server computer and the stored 
information. 

The data storage device stores a program, also refenred to herein as a Peer 700» for 
35 controlling the processor of a device 1 02, 1 04, 106, 1 08. The processor performs instructions of 
the program, and thereby operates in accordance with the present invention, and particularly In 
accordance with the structures and methods described in detail herein. The present Invention 
can be embodied as a computer program developed using an object oriented language that 
allows the modeling of complex systems with modular objects to aeate abstractions that are 
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representative of real-world, physical objects and their interrelationships. However, it would be 
understood by one of ordinary sidll in the art that the invention as described herein can be 
inpiemented in many different ways using a wide range of programming techniques as well as 
general purpose hardware systems or dedicated controllers. The program may be stored In a 
5 compressed, uncompiled and/or encrypted fcnnat. The program furthermore may include 
program elements that may be generally useful, such as an operating system, a database 
management system and "device drivers" for allowing tiie processor to interlace with computer 
peripheral devices. Appropriate general purpose program elements are known to those skilled in 
the art, and need not be described in detail herein. Furtiier, the program is operative to execute 

1 0 a number of invention-specific modules or subroutines including but not limited to one or more 
routines to perfomn object mapping, one or more routines to provide persistence, one or more 
routines to journaiing, one or more routines to provide querying, one or more routines to provide 
schema validation, one or more routines for compounding documents, and one or more routines 
for synchronizing documents. These routines are described in detail below in conjunction with 

15 the drawings. 

According to some embodiments of ttie present Inventton, the instructions of the program 
may be read into a main memory of Uie processor fi-om anotiier computer-readable medium, 
such firom a ROM to a RAM. Execution of sequences of the instructions In the program causes 
processor to perform the process steps described herein. In alternative embodiments, hard- 
20 wired circuitry or integrated circuits may be used In place of, or In combination with, software 

instructions for implementation of tiie processes of the present invention. Tbus, embodiments of 
the present invention are not limited to any specific combination of hardware, finnware, and/or 
software. 

In addition to the program, the storage device is also operative to store Process- 
25 containers. The Process-containers are described In detail below and example structures are 
depicted witti sample entries in the accompanying figures. As will be understood by those skilled 
in the art, the schematic illustrations and accompanying descriptions of the sample Process- 
containers presented herein are exemplary an^ngements for stored representations of 
information and logic. As witti the program, any number of ottier arrangements may be 
employed besides those suggested by tine Images shown. For example, even tiiough a 
particular number of Process-container components are illustrated in a given drawing, the 
invention could be practiced effectively using any number of functionally equivalent components. 
Similarly, the Illustrated layers of the program represent exemplary information only; those skilled 
In tiie art will understand that the number and content of tiie layers can be different from those 
Illustrated herein. 



D. PR06RAIM 

As indicated above, it should be noted tiiat although the example embodiment of FIG. 7 
is illustrated to include a particular number of layers, otiier arrangements may be used which 
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would still be in keeping with the spirit and scope of the present Invention. In other words, the 
present Invention could be implemented using any number of different layers or structures, as 
opposed to the ones depicted In FIG. 7. Further the individual layers could be stored on different 
servers {e.g. located on different storage devices in different geographic locations). Liltewise, the 
5 Process-containers could also be located remotely from the client device 1 02 and/or on another 
server device 108. As indicated above, the program includes instnjctions for retrieving, 
manipulating, and storing data In the Process-containers as necessary to perform transactions 
according to various methods of ttie Invention as described below. 

10 1. PROCESS-CONTAINER OVERVIEW 

As defined above, the Process-container is a mobile, self-contained, asynchronous, 
executable, visuaiizeable agent that has advanced presentation, logic, and data layers that may 
be embodied using XML-Web-Java standards. Each Process-container Instance represents a 
Individualized 'macro' application that supports the Implementation of sophisticated peer-to-peer 

1 5 process application architectures. Process-containers provide a portable mini-web-site lhat 
captures the best of web sites, database applications, email, and documents. 

Process-containers are 'self-contained*. This means ttiat the Process-container is in 
Important ways oblivious to physical location and may operate on any dient or server without 
dependence on network connections, as long as content references are limited to those that may 

20 be satisfied by its own cached internal wortd of content. This 'caching' mechanism gives the 

Process-containers the following characteristics: tolerance of unreliable, nonexistent, and/or low 
bandwidtti connections; ability to scale via leveraging client processing power and reduced client- 
server netwvoric traffic; ability to disperse processing to support fault tolerance and load 
balancing; and a high degree of data-coherency ttiat supports linear performance gains when 

25 used In multi-processor execution platforms. 

Process-containers and the data that they represents are asynchronous with respect to, 
for example, the lifecycle of the databases from which they originated. This implies that Process- 
container resources do not need to be synchronized but If any Immediate or eventual 
synchronization with the original data is desired ttiis may happen through asynchronous 

30 protocols such as optimistic concurrency or checkin/checkout 

The Process-container Peer 

The Process-containers flow, via, for example, email and other protocols, between 
Instances of Process-container Peer. These Peers which may play the role of a Sen/er or of a 
35 Client, nfiay Include a set of Process-container instances, a Process-container Engine, and a set 
of Java servlet ptugins based on a proprietary Extension API. If the Peer Is on the client, then 
tills Peer will usually be embedded into an application such as Microsoft Outiook for example. 

Process-container Presentation 
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The presentation part of a Process-container may be rendered in a standard HTML 
environment. The author of a Process-container may use HTML, Javascript, CSS, and other 
MIME resources in any combination desired to create an appropriate highly adaptive 
visualization of the Process-container contenL 

Process-container Logic 

The logic part of a Process-container may be executed in the Process-container Engine 
to drive manipulation of presentation and data layers. This may be authored using a combination 
of the XCL API and/or JavaScript API. 

Process-container Data 

The data part of a Process-container may include a combination of instances of the 
MIME Process-container Resource and/or the XML Process-container Transaction. 



1 5 Process-container Journal 

All manipulations of the Pn>cess-container either from executing the Process-container 
or via and Extensions, may be Joumaled. This 'logging' behavior is used to support many 
important low and high level features in the Process-container platform. 

20 2. THE PROCESS-CONTAINER SYSTEM 

Turing to FIG. 2, the Process-container System has an uniquely flexible distributed 
system architecture based to a large degree on the mobile, self-contained, asynchronous 
properties of Process-containers. The Process-container System environment Is a peer-to-peer 
architecture where Process-containers are hosted and executed on instances of a Process- 

25 container Engine which may be configured to play the role of a Process-container Server or a 
Process-container Client. The Process-containers may move freely from Server to Client, Client 
to Server. Server to Sender, and Client to Client. The engine architecture may be identical 
whether it Is acting as a client or a server. This fundamental symmetry provides for great 
flexibility when setting up Process-container distribution architectures. 

30 The peer-to-peer architecture described above is based on the concept that Process- 

containers are self-contained and may be moved around using asynchronous protocols. These 
asynchronous protocols mean that one may build scaleable and robust applications. 

A notable feature of the peer-to-peer architecture of the present Invention Is the use of 
messaging. This asynchronous model of sending packets of infbnmation with defen^d return of 

35 status or data, Is enabling infrastructure. The peer-to-peer model of the present invention Is built 
on top of Sun Microsystems Java J2EE messaging technology so that peers may communicate 
with peers through robust scaleable streams of information that may be implemented on top of 
any store and forward messaging product Including the very Important and ubiquitous EMail 
server infrastructure. 
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Process-container Peer 

Turning, to FIG. 3, a Process-container Peer Is defined to be a Process-contalner- 
enabied process running on a suitable Peer Host This process preferably includes a suitable 
5 Java Virtual Machine (Java VM) along with a serviceable Java Servlet Container. Situated in this 
Servlet-container, and running in the Java VM, is a Process-container Engine, that provides 
basic Process-container creation, destnjction, execution, manipulation, and persistent storage, 
along with a standard Java-based plug-in functionality extension backbone called the Ejctenston 
API. This Peer may function as either a Server or a Client depending on its desired usage and 
10 configuration of Extensions. 

Servlet Container 

The Servlet container may be any J2EE servlet specification compliant server 
infrastructure. This may be used to support the startup and shutdown of the Process-container 
15 Engine and to manage HTTP requests. 

Extensions 

The Extensions installed into a Process-container Engine provides a Java based 
extension capability to enable more complex processing, protocols, and connectivity. Extensions 
20 . may be implemented as servlets with a special set of capabilities as defined in the Extension 
API. 

Process-container Server 

Turning to FIG. 4, the Process-container Server may be implemented as a Process- 
25 container Engines placed into one's choice of Servlet Conformant web and application servers. 
The Process-container Server strategy is to not necessarily build, but to enable, server side 
infrastructure. 

Process-container Client 

30 The Process-container clients may be embodied in two distinct fonns: the unenabled and 

the enabled client 

Unenabled clients 

Turning to FIG. 6, the unenabled client may be Implemented as a simple thin-client 
35 wherein the client only requires a browser or other visualization tool. This browser may connect 
to a Process-container Engine on another host using standard HTTP protocols. 

Enabled clients 



-14- 



wo 02/05106 



PCT/USOl/21462 



Turning to FIG. 6, an Enabled client is a peer-style client that has almost all of the 
capabilities of an individual Process-container Sender to add to a Process-container Client 
application environment. 

5 Serviet Container 

The Process-container Environment includes the concept of a low-footprint 'Serviet 
Container' that has Just enough functionality to support the Itfecyde of multiple Servlets with 
basic HTTP protocol support and just enough functionality to support a Process-container 
enabled Client This the single-user client version of the server side multi-user Serviet Container 

10 

Server as Client 

Strictly spealOng, this Serviet container is only necessary for applications that do not 
have one already, however this includes most applications except for the case of a WEB server 
acting as a cllenL In general this scenario falls under the category of a server (peer) talking to 
1 5 another server (peer) and is not covered in this chapter. 

Types.of Enabled Clients 

There are various types of enabled client scenarios that may be supported. These may 
include Email Agents, Beans compatible Applications, ActiveX control compatible applications, 
20 and DLL applications. Since the Process-container is very naturally treated as an email, it is a 
natural to use In an email application such as Microsoft® Outlook® or Lotus® Notes®, The 
Process-container Environment may also support the concept of Process-container embodiment 
in the form of a Java* Bean*, an ActiveX* control, and a Windows* Win32 dll. 

25 Process-container Enabled Clients 

The overall client architecture for process-container-enabled applications Is based on a 
low footprint version of the Process-container Engine combined with a Process-container 
•enabler" component interacting with the application's Presentation, Logic, and Data layers and 
oonnecb'ng its semantics to the semantics of the Engine. 

30 

Client versus Peer role 

This discussion focuses largely on the problem of single-user GUI based applications, 
but may be extended In many aspects to the more general problem of a peer-to-peer architecture 
where the concept of a client and a server are more accurately thought of as roles played In a 
35 given interaction, and not as limitations of capabilities. 

Process-container Engine 

Turning to FIG. 7. the Engine Java Object is the heart of the Process<jontalner Java run- 
time environment It Is responsible for choreographing the run-time lifecycle of Process- 
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containers in all its aspects. It is used to 'process-container-enable* any 'servlet-enabtecf 
application or web sewer. The Engine contains the following components: 

The Architectural Layers 
5 The layers within the engine architecture may Include a Support Layer, a Runtime Layer, 

a Core Layer, a Process-container Layer, and a Execution Layer. In addition, the architecture 
may further include application programming Interfaces (APIs) such as an Extension API, a 
Javascript API, and a XCL API. 

10 3. THE SUPPORT LAYER 

Turning to FIG. 8. the Support Layer is a set of third party Java packages that are 
Integrated with the Process-container Engine so as to support both Internal Engine functionality 
and Process-container Extensions developed using the Extension API. This means that the APIs 
that are specified at the Support layer are available to all Engine code and Extension code. It is 

1 5 also pennisslble to reference these types directly in the€xtension API. 

The Support layer preferably provides compatibility between the Process-container 
Client and Process-container Server environments. This means that as much as possible, the 
packages provided at in the support layer are guaranteed to be available in both environments. 
However the exact capabilities of each package, based on tocal drivers/providers available, may 

20 vary. 

The Server side may run in a commercial J2EE environment ninning on a version ^2 
compatible Java VM. IWany clients however, run on a Microsoft 1 .1 .6 VM and likely would have 
difficulty supporting the heavy footprint of a full J2EE environment The present invention solves 
this situation by providing a different Extension environment on the client that provides minimal 
25 JMS/JNDI functionality. 

As in the particular example embodiment described herein, the Support Layer may 
include the following support packages: ECMAScrlpt, Xerces DOM/XI^L, Xalan XSLT/XPATH, 
Java JNDI, Java JMS, Java JAF, Java JavaMail. and Java Servlet 

The Support Layer provides a JavaScript interpreter package that confomns to ECMA- 
30 262, revision 3 created by the ECMA Technical Committee TC39. This Is to support the 
Execution Layer in Its support of the Javascript API. For example, the Rhino 1.5 package 
described at:http://www.mozilla.org may be used. 

Tlie Support Layer provides a W3 compliant XML parser. For example, the Apache 
Xerces package available at: http://xml.apache.org/ can be used. This supports the following 
35 XML standards: Document Object Model (DOM) Level 2 Specification Version 1 .0 W3C 
Candidate Recommendation 10 May, 2000; Extensible Markup Language (XML) 1.0 W3C 
Recommendation 10-February-1998; SAX, the Simple API for XML which is a standard interface 
for event-based XML parsing that was developed collaborativeiy by the members of the XML- 
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DEV mailing list hosted by OASIS; XML Schema Part 1: Structures W3C Working Draft 7 April 
2000; and XML Schema Part 2: Datatypes W3C Working Draft 07 April 2000. 

The Support Layer may provide a W3 compliant XSLT/XPATH processor. For example, 
the Apache Xalan package available at: http://xml.apache.ofq/ may be used. This pacloge 
5 supports the following XML standards: XSL Transformations (XSLT) Verston 1 .0 W3C 
Recommendation 16 November 1999 and XML Path Language (XPath) Version 1.0 W3C 
Recommendation 16 November 1999. 

The Support Layer may also provide a Java J2EE compliant Servtet package, a Java 
J2EE compliant JNDI package, a Java J2EE compliant JMS package, a Java J2EE Release 
1 0 JavaMail release 1 .1 .3 package, and a Java J2EE compliant JM= package. 

4. THE RUNTIME LAYER 

Turning to FIG. 9, the run-time layer is a set of Java interfaces and Implementations that 
support general run-time characteristics of the Process-container Engine. This layer depends on 

15 the Support Layer below it and provides capabilities to the Core Layer and above. This layer 
may Include the following Java subsystems and interfaces: Persistent Store Subsystem; 
Process-container Session Subsystem; Verb Protocol Subsystem; Process-container Event 
Interface; Process-container Attachment Interface; Process-container Packet Interface; Process- 
container EmaD Interface; Process-container Message Interiace; and Process-container Service 

20 Interfiace. 

Persistent Store Subsystem 

While this capability exists at the Run-time layer, is it addressed in the Process-container 

Store. 

26 

Process-container Session Subsystem 

Turning to FIG. 10, the Process-container Session subsystem within the ain-time layer, 
is responsible for managing issues of flow of control, authentication, transactions, and resource 
managemenL 

30 

Flow of control 

Within the Process-container Engine all threads doing useful work preferably have a 
Process-containerSession associated with them. 

35 Authentication 

When the Session is created, an authentication context is preferably built 

Resource Management 
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Sessions include the concept of owning various resources within the Process-container 

Engine. 



Transactioris 

5 Sessions will align with Java JTA transactions models for use when accessing EJB. 

JDBC. MS and other J2EE resource managers. 

Process-container Event Interface 

10 Process-container Message Interface 

Turning to FIG. 11, the Process-oontainerMessage is the mechanism whereby various 
Process-container objects are externalized for movement in JMS queues. This is to support 
interactions between Extensions and executing Process-containers. 

15 MliyiEForm 

Illustrated In FIG. 12, the MIME form of the Process-container is where the previously 
described Email object from the Document form Is extracted to create standard EMAIL parameter 
header, and an associated IVIIME structure (tree). The previous document iom is then inserted 
into the MIMB structure as a M\MB attach-ment This 1^1 ME fomfi Is appropriate for transport over 
20 normal email protocols (SMTP. (MAPI. MAPI, POP). 

A Process-container Attachment Interface, a Process-container Pacicet Interlace, and a 
Process-container Email Interface may also be provided. 

25 Process-container Service Interfiace 

Turning to FIG. 13, Services within the Process-container engine are now discussed. 
Service Interfaces may be accessed from Java Extensions via JNDI and/or XCL JavaScript 
Rules via special script bindings. 

Service Interfaces may be implemented using Java objects in the Engine and/or Java 
30 objects in Extensions. Services provide a uniform way to support and control accesses between 
various parts of the Engine ain-lime environment 

Lifecyde 

Services have special startup and shutdown semantics. They are assumed to place 
35 themselves Into the JNDI name space and register themselves with the Engine. 

Authentication 

Sen/ices support the concept of session and authentication. Any thread entering through 
a Service interfiace boundary will preferably be attached to a Process-container Session 
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Subsystem implementation appropriate for validating and controlling access to resources withhi 
the service. 

Script Bindings 

5 Sen/ices may be accessed from XCL Rules via through the Process-container Javascript 

APi. The Service when it is registered with the Engine, telis the Execution Layer logic to maice 
the interface available to running JavaScript 

Client side services 

10 Since many Services will be implemented using Extensions, it is important to consider 

that Javascript that relies too heavOy on Services may be placing undue requirements on the 
ubiquity of a particular Service Extension it has become dependant on. 

Verb Protocol Subsystem 
1 5 Turning to FIG. 14, the Engine may always be hosted In a Servlet container this is either 

a Web Server that is capable of hosting Servlets as in the Process-container Server, or a low 
footprint Servlet Container of the present Invention as in the Process-container Client. This 
Servlet container provides the most basic of njn-tlme environments: a startup and shutdown 
within a Java VM, and a HTTP server protocol implementation. 

20 

Verb Protocol 

The Servlet container is configured to start up the 'Verb Dispatch Servlet". This single 
Servlet starts up the Engine in the local Java VM and also starts up a set of hard-wired 'Verb 
Servlets'. Each of these verb servlets registers a particular Verb' associated with the some 
25 HTTP request type. This allows the engine to create URIs of the form: 

http://some.host.com/some/process-contalner/servlet/path/verb?<parameters> These URIs are 
used to establish what is called the 'verb-protocol* or set of verbs with specific parameters that 
the engine Is gusiranteed to respond to as HTTP requests. One verb type Is the . 

30 5. THE CORE LAYER 

The Core Layer is a Java class library that builds on top of DOM level 2 functionality to 
create a Java XML Object based environment, it supports the semantics of the Process- 
container Layer, and builds on top of the semantics of the Runtime Layer. 

35 Core Layer Capabilities 

The Core layer includes the following capabilities: 

Java Object Mapping 
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Within the Core Layer, once an XML document is parsed into a special Core Layer Java 
object with the IsiDocument interface. aH elements within it may be accessed as special Java 
objects. 

5 Persistence 

Since ail Java Objects built using the Core Layer are backed by a DOM tree, they may 
be externalized in the same way that XML may be externalized. 

Joumaling 

10 The Core Model has special hooks to support the concept of a Process-container 

Journal. This is done through supporting the appropriate event structure to provide hoolcs for any 
changes to underlying Core objects. 

XPATH queries 

1 5 The Core Model using the Xaian XSLT/XPATH package, supports unlimited queries on 

the Core Model. Queries retum Core Model objects. 

Schema Validation 

The Core Model supports schema validation as supported in the Xerces DOM/XML 
20 package. 

Compound Documents 

The Core Model supports the manipulation of documents that may inserted into, and 
withdrawn from, other documents. 

25 

Core Model level synchronization 

The Core Model's synchronization model is that all documents and their contained 
objects are un-shared. This means that the Core Model assumes, but does not enforce that there 
is only one Process-container Session Subsystem Session 'owning' a document at a time. All 

30 interactions with that document Including manipulation of its subordinate objects do not have to 
be synchronized once that document is owned. This document level granulartty melds well with 
Support Layer support systems concurrency semantics. This is, however, a huge assumption in 
that if it ever becomes necessary to support lots of concurrent access to a given document, that 
this would become a concun'ency hot-spot and its coarse grainedness while simple and robust 

35 may not scale appropriately. 

Core Model Interfaces 

Shown in FIG. 15 are the Core Model interfaces. The islNode 1518 represents a 
wrapper on top of a DOM Node 1520 that supports basic node-level behaviors. This type 
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supports XPATH queries. The IsIAttributo 1510 represents a vwgpper on top of a DOM Attribute 
Node that supports basic attribute-ievel behaviors. The IslText 1514 represents a wrapper on 
top of a DOM Text Node that supports basic text behaviors. The IslComment 1516 represents a 
wrapper on top of a DOM Comment Node that supports basic comment behaviors. The IslValue 
5 1 512 represents the ability to manipulate the content of a DOM attribute or a DOM element as a 
value in symmetrical manners. Values are simple literals such as String, Float, Integer, and Date. 
The IslObject 1508 represents the ability to manipulate a DOM Element as a structured Java 
Object with its content being other contained IslNodes. The IslDocument 1504 represents the 
ability to manipulate a DOM Document Element 1502 as a structi^ed Java Object v\rith its content 
1 0 being other contained IslNodes 1 51 8. This type supports Object Factory and DOM-Java 

Mapping. The IslGeneric 1506 represents a subtype of the IslObject 1508 class meant to hold 
XML nodes that are not mapped into the Object Factory. 

Core Subtype 

15 The Core Model, Illustrated In FIG. 16. provides both an Interface and Implementation 

Hierarchy. These are used to support the creation of custom object and document subtypes as 
well as supplying core semantics by support the subclassing of appropriate core and document 
subclasses. This supports a very Java-XMLbased programming model for all layers above the 
Core Layer in the Process-container Engine. 

20 

Generic Object 

When an XML element is encountered that does not have a custom mapping, then the 
IslGeneric mterface and CslGeneric class are used. 

25 DOM-Java Mapping 

As shown in FIG. 17, the Core Model may Include two parallel trees: (1) a DOM 
document and (2) a lazily constructed Core Model Document 



Tree Linking 

30 These two trees are linked together by a combination of a reference from the Java Obect 

to the DOM Node, and a hashtable lookup of the Java Object based on the DOM Node as a key. 
This reverse linkage lookup avoids having to change the interface of the DOM API. This linkage 
management Is done by the IslDocument implementation. 

35 Lazy Construction 

The extra price of having two parallel trees, both in complexity and performance, is 
mitigated to a certain extent by having the Java Object tree constructed lazily. This means that a 
given node in a given DOM Uee only has its linked Java Object created vtfhen a direct request is 
made for it via a Core Query, some other Cone Model tree manipulation. 
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Object Factory 

The Java Object for a given DOM Element is constructed by an Object Factory based on 
three criteria: a DOIVI tag name and an Interface Specification. So as a given element Is 
6 constructed, tlie Object factory does a lookup on first the interface specification and then if that is 
missing, the DOM tag name, and If that Is not found among the Factory's registered types, then 
the Generic Object is returned. 

interface Specification 

10 <element1 process-container:!nterface='java.package.name.CoreSubtype'> 

In order to support the ability to construct an XML element without having to specify the 
element name, the Interface specification is used. This attribute, if found, ovemdes any Element 
name mappings. 

15 Model 

Turning Id FIG. 18, the Core Model supports the registration of custom object and 
document subtype interfaces and implementations through a concept called a Model. The Model 
provides these types to the Object Factory to use when mapping DOM elements to Core Subtype 
instances. 

20 

Markers 

<element1 process-contalner:Markep='3*> 

The Marker Is a core model specific attribute that is used by the Core Model to map the 
identity of a given DOM element in a tree to a particular Java object. This is what creates the 
25 Tree Linking from the DOM node to a possible previously constructed Core Model object or 
document. This is used for Instance to map the results of an XSLT query to a pre-existing Java 
object. 

Data Typing Is also available. 

30 6. THE PROCESS-CONTAiNER LAYER 

The Process-container Layer is built on top of the Core Model Layer and includes the 
following major components: a Process-container; a Process-container Resource; a Process- 
container Binder; a Process-container Transaction; a Process-container Attachment; and a 
Process-container Journal. 
35 Turning to FIG. 1 9, the Process-container may be decomposed Into one or more 

Instances of a Binder, a Process-container Journal, one or more Instances of a Process- 
container Attachment, and one or more instances of a Process-container Transaction. 

Process-container identity 
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Each Process-container has an application defined URL that uniquely identifies the 
Process-container over Its full lifecycle. Only one Process-container of a given Identity may be 
hosted within the same Process-container Engine at the sanne time. 

5 Process-container Lifecycle 

Turning to FIG, 20, Process<ontalners are created, destroyed, have one or more 
Instances of Binder, Attachment, and Transaction added and deleted from them, and are moved 
around via the Extension API. 

1 0 Process-container Shell Annotation 

In order to support their execution, Process-containers have a Shell annotation, that 
represents the starting point for interacting with the content of a Process-container. 

Process-container thread synchronization 

1 5 One feature of the Process-container engine is that the run-time session support 

enforces session thread serialization at the Process-container granularity. This means that in 
general write permissions on a Process-container may belong to only one Session at one time. 
This allows session threads which have ownership of a Process-container to freefy access most 
elements of the Process-container without concern about concurrency conflicts. This is a 

20 significant benefit of the asynchronous self-contained agent modei of the present invention. 

Having a coherent complex object means that on a multiprocessor engine the complete Process- 
container with all of Its contained objects, may be in whole or in part, localized to a single process 
cache. This avoids frequent cache-fiushing which usually distorts otherwise linear performance 
scaling as processors are added. 

25 

Process-container run-time Lifecycle Modes 

The Process^container has three operation modes: Active, Execution, and Inactive. The 
Active operational mode of a Process-container occurs when the Process-container has been 
fetched. In the Execution operational mode, when an HTTP Page request Is received that directs 
30 the Process-container Engine to start execution on a Process-container, a Page Context Is 
created for the Process-container. The Inactive mode results after the Process-container is 
flushed to disk (and the Java object has been abandoned). 

Process-container as a Document 
35 Process-containers share many concepts in common with Documents like Microsoft* 

Word® files. These may include verbs such as Open; Ctose; Save; Revert; Undo; and Redo. A 
Process-container may be opened. This means to initialize the Process-container Including 
rolling fonnrard the In-memory Image to match the last saved persistent image. This Is done using 
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the Process-container Journal. Almost ali operations on the Process-container, will preferably be 
performed after the Process-container Is opened. 

A Process-container may be closed. This means to free up a resources that the Process- 
container may be holding down, and freeing up the assodated Java object, if the in-memory 
5 Process-container Object is not saved (its content not synchronized with the persistent image in 
the Process-container Store), then its changes will be lost. When a Process-container is saved, 
Its in-nfiemory image is synchronized with Its persistent Image in the Process-container Store. 
When a Process-container is reverted, then its In-memory image is rolled bade, using the 
Process-container Joumal. to match the last 'saved* persistent Image. When the undo verb Is 
10 received, the Process-container roils-bacl< the in-memory state using the Process-container 
Journai, that reflect the in-memory state that was in force before the last external event was 
received by the Process-container. When the redo verb is received, the Process-container rolls- 
fonward the In-memory state using the Process-container Joumal, that reflect the in-memory 
state that was in force before the last undo was perfbnmed 

15 

Process-container Binder 

Turning to FIG. 21, a Process-container Binder is a set of Process-container Resource 
instances that Process-container authors use to organize Process-container functionality into 
identifiable, downloadable objects. They are the Process-container analog of the Java JAR file. 

20 

Meta-data 

Binders are considered meta-data. They preferably are not be updated by the Process- 
container during execution and may be shared as necessary between Process-containers. 

25 Binder Identity 

Each Binder may be uniquely located and identified via a URL. This identity and location 
is set by the Author when the Binder is developed . 

Binder Downloading 

30 The Binder may be downloaded by refisrenclng its URL. This cached downloaded may 

then be shared between Process-containers as they reference the same Binder. 

Binder Lifecycies 

The Binder is placed Into and removed from Process-containers at any poinl during the 
35 Process-container LIfecycle. Binders may be placed into the Process-container by different 
engines on behalf of separate appllcalions. 

Process-container Transaction 
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Transactions are one veiy special type of Process-container Resouftje that is an XML 
document that represents transactional data wittiln a Process-container. Tliese documents have 
the following special processing applied to them during the Process-container lifecycle: they go 
through spedal 'import and 'export' processing to add or remove them from the Process- 
5 container; ail physical level data changes are 'logged' and are undoable; and if desired, 
compliance to an external DTD or other XML schema standard Is enforced. 

Process-container Attachment 

Process-container Attachments are a type of Process-container Resource that Is any 
10 arbitrary MME bytestream that Is Instance data intended to be accessed by one particular 
Process-container. This would include such things as specific Office documents added to the 
Process-container. 

Process-container Resource 
1 5 One of the most salient aspects of a Process-container is Its inherent support for 

aggregations of an arbitrary URL Identified MiME 'Resources' In encrypted, compressed binary 
encoded form within the Process-container XML. 

Resource VURL 

20 The URL of each Resource may be considered a 'virtual' URL In that the Process- 

container Engine manages run-time refierences to a Resource URL through a virtual to physical 
mapping layer that allows the network identity to be remapped a local cached version made 
physical through the Process-container Engine. In this manner, all Process-container contained 
Resources are free to move from physical engine to physical engine and have the associated 

25 Process-container content accesses guaranteed to always succeed. The Process-container 

Engine contains services that support the 'swizzling' of content or the replacement of abstracted 
virtual Resource URLs (VURLs) with appropriate Resource PURL Instances. 

Resource PURL 

30 Resource PURLs represent concrete, physical URLs that are replacements made by the 

Process-container Store to be used by the external Browser rendering component, to access a 
'local' cached version made when the Process-container was 'docked* in that Process-container 
Engine. 

35 Opaque Resources 

Many of the Resources contained in a Process-container are simple binary byte streams 
that represent content that is not further Interpreted by the Process-container envlronmenL 
Examples of opaque resources include images, audio, video, binary data files, and non-XML 
documents. 
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Object resources 

Many of the Resources contained within a ProcessHJontalner represent documents that 
the Process-container Engine considers interpretable or non-opaque. These are mostly XMl 
6 documents, but include such files as Javascript and Cascading style sheets that are also 
'understood' by the Process-container run-time as other than an opaque byte stream. These 
interpreted Resources are converted to specialized Engine 'Objects' that support many things 
indudtng the 'swi2zling' of relevant properties of the understood object. 

10 Meta-data Resources 

Many of the Resources contained within a Process-container are considered 'meta-data'. 
These meta-data Resources are read-only, shared, and are expected to have matching content 
and Identity from one Process-container to another. Meta-data defines the type* of a Process- 
container. 

15 

Data Resources 

Many of the Resources contained within a Process-container are considered 'data'. 
These data Resources are private to the Process-container, writeable, and are expected to have 
varying content from one Process-container to another. Data is where the 'instance' properties of 
20 a Process-container are stored. 

XCL Documents 

Some of the content, in most cases Meta-data Resources, contain a Process-container 
specific dialect of XML called XML Component Language (XCL). This dialect of XML is used to 
25 annotate other forms of XML such as HTML. XSLT, and Transactions to Process-container- 
enable the presentation, logic, and data of the contenL XCL is discussed in much greater detail 
below. 

Process-container Journal 
30 The Journal model Is a set of objects built on top of the Core Layer. Each Process- 

container may Include an integrated joumaling system with a Journal object 

Mutations 

The Journal is a linear sequence of Mutations. Each mutation reflects a change In state 
35 of the Procesfr<jontainer. Mutations are grouped into 'cycles' which means a set of Mutations 
reflecting those changes associated with a single external event! 

Physical joumaling 
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Physical Joumaling is where ail interactions with Process-container Resources that 
represent Instance data, including Process-container Transactions, Process-container 
Attachnnents, have all changes made to them logged in the Journal. This logging behavior is 
used to support Process-container as Document; Asynchronous Synchronization Protocols; and 
5 a Replication Protocol. 

Logical joumaling 

Logical Jounnaling is where all Interactions with the Process-container at a logical level 
are recorded. Examples are those Process-container state changes that are not directly physical 
10 ©vents on a Process-container Resource. For Instance logging of Publish/Subscribe Parameter 
events and in general presentation layer events. Logical joumaling includes support for Process- 
container as Document 

Application Joumaling 

1 5 Application level joumaling is where Extension API applications or XCL Rule instances 

may create events that are logged for later retrieval to support specific Process-container 
Interacting undo/redo behaviors. 

Security and Authentication 
20 The Journal supports a specific security model where segments of the Journal attributed 

to various people or systems may be isolated, possibly encrypted, and possible digltaDy signed. 
This Is discussed In the Journal Security Model. 

Journal Playback 

25 Java Applications using the Extension API, may Interact with the a Process-container's 

journal using the Process-containerJournal object. This object aliovi/s the user to step forward or 
back through a Process-container's log and capture the sequence of events to support 
synchronization or data pro-filing. 

30 7. THE EXECUTION LAYER 

The Execution Layer is a set of Java Interfaces and classes that support the execution of 
Process-containers. The Execution layers builds on top of the semantics of the Process- 
container Layer, and supports the semantics of the Javascript API and XCL API. As illustrated in 
FIG. 22. this layer may include the following Java subsystems and interfaces: Page Context 
35 2212. Browser Model 2214, XCL Component Model 2204. XCL Component Type Model 2202, 
HTML Model 2216. XSLT Model 2206. JavaScript Support 2210, Page Protocol 2218, and a 
Scheduler 2208. 

Execution Overview 
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The Proces&K^ontainer is executed by first locating the Process-container She)) 
Annotation spedfied in the Process-container, activating the specified XCL Component in the 
specified XCL Library. This activation In turns activates and executes all referenced Component. 
This sheil annotation acts lilce a caii to maln{) as in C, C++, and Java. The result of this 
5 processing is to create a Page Context that renders itself to a remote Browser, and then waits for 
external events over the Page Protocol. The requests are processed through the Page Context, 
potentially causing a wave of Components to be scheduled, and then re-rendering as appropriate 
to the remote Browser. 

10 XCL Syntax Support 

The XCL syntax, since it is a tree of intermixed and nested XCL and non-XCL markup, 
may be activated as a Core Layer Java Object model tree that contains both XCL IVIodel objects. 
HTML Model objects. XSLT Model objects, and Opaque XML Model objects. 

15 XCL Model 

The XCL Mode) is the combination of the XCL Component IVIodel and the XCL 
Component Type Model. 



Opaque XML Model 

20 Much of what is processed by execution layer is XML by vMai are called Generic Object 

instances. These undergo no special processing other than scanning for special XCL directives. 

XSLT Model 

The Execution layer supports an enhanced XSLT model that altows the user to 
25 manipulate the XSLT content of a transform. 



HTML Model 

The Execution layer supports an enhanced HTML model that allows the user to 
manipulate the HTML content of a Page. 

30 

XCL Component Mode! 

As shown In FIG. 24, the component interfece hierarchy includes several Java interface 
classes. The IsiScope interface represents the XCL scoping behavior for an XCL subtree.. This 
is used to conlroJ the flow of events, variable lookups etc. The IslFunctlon interface Is used to 
35 model the functional aspects of an XCL subtree. This Includes parameterization, 

publish/subscribe variables etc. The IslActive internee represents a XCL subtree that may 
undergo Activation, Evaluatk)n. Execution, and Deactivation. The IslComponent dIrecSy 
supports the XCL Component construct The IslAnnotation directly supports the XCL Annotation 
construct. The IslVariable directly supports the XCL Variable construct The IslVariable directly 
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supports the Component Parameter construct The IsIPublish directiy supports the XCL Publish 
Variable construct The IsIPublish directly supports the XCL Subscribe Variable constmct. The 
IslLibrary directly supports the XCL Libtary construct. 

5 XCL Component Type Model 

As shown in FIG 25, the component subtypes interface hierarchy may include the 
following Java Interface classes: 

Query 

10 The IslQueryComponent and the IslQuery internees support the Query Component and 

Query Annotation XCL constmcts respediveiy. 

Transforms 

The IslTransformComponent and the IslTransform Interfaces support the Transfonm 
1 5 Component and Transform Annotation XCL constructs respectively. 

Swatch 

The IslSwatchComponent and the IslSwatch interfaces support the Swatch Component 
and Swatch Annotation XCL constructs respectively. 

20 

Rule 

The islRuIeComponent and the IslRule interfaces support the Rule Component and Rule 
Annotation XCL constructs respectively. 

25 JavaScript Support 

There are various ways that the Execution layers supports access to ECMAscript and 
the Javascript API of the present Invention. These may Include: the XCL Rule via the XCL API 
and the XSLT javascript extensions. 

30 Page Context 

Turning to FIG. 26. the Page Context Is the execution image for an executing Process- 
container. It is divided into two distinct sub-trees; the Execution Tree and the Result Tree. Also 
associated with tfie Page context are a set of Page Variables and some Global Stnjctures. 

35 Page Variables 

The Page contains a set of XCL Variable Instances that contain run-time data of the 
page. These are used in PageScopes to make these variables available to the executing XCL. 

Global Structures 
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There are a set of global structures in the Page Context These may include a Scheduler 
and an Article Manager. 

Execution Tree 

5 The scope tree In the page structure contains what amounts to the tree version of a ain- 

tlme execution stack. 

Result Tree 

The content tree In the page structure contains a tree that Is the final visible results of the 
1 0 current page event cycle. This is HTML in a browser-independent fonn. 

Page Llfecycle 

Turning to FIG. 27, the Page Context lifecycle is based on the concepts of activation, 
deactivation, stabilization and destabilization. 

15 

Deactivated 

Until the first Page Request on given Process-container is received, the Page Context is 

non-existent (deactivated). However, when the Process-container receives its first page-request, 
it checl^s to see if the Page Context Is extent (activated), and if not activates it (creates the page). 
20 Once the Page Context is available, the request is passed to It, which Immediately makes it 
'unstable' because the first page-request requires a page response. 

Unstable 

When a Page Request is received, the page immediately becomes unstable, and the 
25 execution layer's main job is to achieve Page Context stability. This is achieved by processing 
the request, and generating an appropriate Page Response. 

Stable 

After the Page Response is generated, It goes into a quiescent state where no more 
30 Components may be scheduled. 

Page Protocol 

Turning to FIG. 28, the Execution Layer uses the Verb Protocol Subsystem to provide a 
verb called the page-request verb to support a series of possible external manipulations of the 
35 Page Context. This external manipulation of the Page Context is called a Page Action. 

Page Request 

A Page Request is an HTTP request coming into the Page from the local Servlet 
Container. This page request contains a URL which represents a combination of the desired 
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Page Action, the appropriate Process-container/Page as the target for this request, and the data 
associated with the Action. This request is forwarded through the page-request verb and is 
processed into a page action that is sent to the Page Execution Logic. 

5 Page Execution Logic 

The Page Execution logic is where the Page Action is interpreted and appropriate 
processing is perfomied on the state of the Page. The Page Execution Logic may include the 
fbilowing elements: Action Processing, Scheduler* and Browser Model. The Execution Logic's 
main job is to stabilize the Page Context after it has received a Page Action. Once this 
10 stabilization has occurred, then a Page Response may be generated. 

Page Response 

The Result Tree of a stabilized Page Context may be rendered to create the appropriate 
HTTP response to be sent bacl< to the Browser Client 

15 

Action Processing 

Pages may react to various Page Actions. Each of these actions is processed 
individually. 

20 Page Action 

A Page action may come in the following fonms: Visualize Action, Opaque Action, Update 
Action, Undo Action, and Save Action. 

Visualize Action 

25 The visualize action may be used for the following reasons: Page Activation which leads 

to initial rendering of Results Tree; and Page Refresh which leads to a complete re-rendering of 
the Results Tree. 

Opaque Action 

30 The Opaque Action is used for communication between the Browser Client and the 

Browser Model. It is interpreted by the Page Context directly. 

Update Action 

The Update Action is used to send updates from the Browser Client to the Page Context. 
35 These updates are browser events potentially conveying data. 

Undo Action 

The Undo Action is processed to roll-back the state of the Page Context to the last 
stabilized state. 

-3J. 
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Redo Action 

The Redo Action is processed to roll-forward the state of the Page Context to a 
previously undone stabilized state. 

5 

SaveAction 

The Save Action is processed to persist the current state of the Process-container. 
Revert Action 

1 0 The Revert Action is processed to roil-t)aclc the in-memory state of the Process-container 

and Page to the last persisted state of the Process-container. 

Page Activation 

Turning to FIG. 29, Page Activation is where the Page Context structures are 
1 5 constructed for the first time. 

Page initialization 

The first phase of Page activation is where the Page Context Is set up for the first 
Component Scheduling, the Shell Annotation Execution. The steps involved include placing the 
20 initial Dynamic Scope instances at the root of the Execution Tree; placing the HTML root tag at 
the root of the Results Tree; placing the Shell Annotation under the HTIVlL root; placing the Shell 
Annotation Into the Scheduler; running the Scheduler; and building the remainder of the Page 
Result Tree by the Shell Annotation. 

25 Shell Annotation Execution 

The Process-container She!! Annotation v\4ien run acts exactly lil<e other Component 
executions. This builds the Results Tree from scratch. 

Scheduler 

30 Turning to FIG. 30. the Scheduler accepts new XCL Annotation instances for scheduling. 

These Annotations then undergo Annotation Execution according to a Scheduling Algorithm. 

Scheduling Algorithm 

The Scheduling algorithm is based on the following rules in high to low priority order: (a) 
35 if the scheduled Annotation is already in the scheduling queue, then it is not added a second 
time; (b) If the scheduled Annotation Is deactivated, then it is removed from the scheduling 
queue; and (c) the first scheduled Annotation is the first executed (first in. first out). 

Subtree Lifecycles 
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The Page Context is composed of both an Execution Tree and Result Tree both of which 
hciude many individual subtrees that are the result of the execution of Annotations. Each of 
these subtrees has Its own llfecycle which Includes the following phases; the Activation Phase, 
the Evaluation Phase, the Execution Phase, the Deactivation Phase, and the Rendering Phase. 
5 The Activation Phase is where a new subtree, usually part of a Results Set is 

constructed into the Scope of a Page Context for the first time. AH run-times structures are 
initialized and all nested child Annotations are executed at least once. This phase is only run 
once per annotation. 

The Evaluation Phase is where a subtree goes through appropriate attribute values and 
1 0 element contents, evaluating them as an XCL Expression. The content of the attribute or element 
is replaced by the result of this expression evaluation . 

The Execution Phase Is where the previous Results Set members of a given Annotation 
Execution are removed, undergoing the Deactivation Phase, and new Results-set are inserted as 
produced by the execution of the particular Annotation involved. ■ 
1 5 The Deactivation Phase is where the given subtree has ali of its associated run-time 

resources disabled and removed from where they were rooted. This may be run once on a given 
subtree, because after deactivation, the Annotation and ali of its children undergo deactivation 
and are no longer valid XCL subtrees. 

The final form of subtree traversal, the Rendering Phase, is engaged when the whole 
20 Page Context results-tree undergoes Update Rendering. 

Annotation Execution 

Turning to FIG. 31 , when an Annotation is executed, the body of the associated 
Component (or Annotation If it Is an Inline Component), is executed in a manner that is specific to 
25 the associated Component Kind. 

Results Set 

This execution in ali cases returns either nothing, or an XML fragment node set This 
results-set node-set is placed after its previous node as a child in its target 

30 

Previous Node 

The previous node is the node that the Annotation had as a previous sibling and this 
marks where Its Results-set is to go. 

35 Target Node 

The Target node is the same node as was the parent of the Annotation before it was 
taken from its original parent. 

Browser Model 
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Turning to FIG. 32. the Browser Model provides browser-Independence for Process- 
containers. There Is a separate kind of browser model for each supported browser company and 
version. The Result Tree is Interpreted by the current browser model and is output in HTML that 
is browser speciftc. 

5 

Browser 

The Browser Model manages a roughly parallel structure to the page Result Tree except 
that Instead of being a tree of Core Model nodes, it is a set of Peer Instances that represent the 
binding between the Page and the Browser models. 

10 

Peer 

The Browser model is asked to construct Peers for every element In the Results-Tree. 
These Peers In turn are used by the Browser model to build browser-dependant versions of the 
HTML they are to send back to the Browser Client 

15 

Browser Client 

The Browser Client is one of a set of supported HTML rendering clients such as Internet 
Explorer or Netscape communicator. The Browser model builds multi-frame structures using 
JavaScript in the Browser Qient 

20 

Update Rendering 

The Browser model traverses the Results Tree and sends via the Page Response, via 
Targeted Updates, the infonnation needed by the Browser aient to display the current state of 
the page. 

25 

Targeted Updates 

Targeted updates are updates coming from the browser model that are targeted to only 
those parts of the HTML that have actually changed. This means that the structures on the 
Browser aient are optimally redrawn. 

30 

Article Manager 

The article manager is used to support page context structure to support Articles. 
Tuming to FIG. 33. Page Building is illustrated. FIG. 34 Illustrates Event Flow. 

35 

8. XCLAPI 

One very important type of Resource contained within a Process^ntalner are XML 
Process-container Resources which are instances of the XCL Library written following the XML 
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Component Language XCL Source Language. Each of these libraries contain one or more 
instance of XCL Component. 

XCL Source Language 

5 XCL source language Includes XML tags with the XCL namespace prefix 'xcl', and XML 

tags coming from arbitrary other XML dialects. The XCL source language processes certain 
other dialects of XML, HTML and XSLT. with special semantics. Ail other XML Is treated as 
generic XML. 

10 XCL Name 

XCL uses names to identify constnjcts for later refsrenoe. 

XCL Component 

Each of these components In their associated library represent the meta-data defining a 
15 fine-grained, re-useable, event-driven executable module of XML functionality that can be fca/fed' 
within the context of other XCL components. 

Component Encapsulation 

Components are designed to be highly re-useable. modular, coherent semantic 
20 constructs. 

Component Functions 

Components can be thought of as functions in the traditional sense. They have the 
concepts of signatures, evaluation, and return values. Also the encapsulation guarantees of 
25 components are very similar to the type encapsulation of functions. 

Component Kind 

There are four kinds of components: XCL Rule, Rule Annotation, XCL 
Swatch, and XCL Query. 

30 

Component Definition 

Components are specified in the XCL dialect using XCL component constructs. The 
component definition includes the declaration, the signature, and the body. 

35 Component Declaration 

<xcl:Swa1chComponent name='haynes'> 
... swatch component definiUon ... 
</xcl:SwatchComponent> 
<xcl:RuleComponent name='jones'> 
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... rule component definition ... 
</xd:RuleComponent> 
<xcl:TransformComponent name='peterson*> 

... transform component definition ... 
5 </xcl:TransformComponent> 

<xcl:QueryComponent names'drev/> 

... query component definition ... 
<yiccl:QueryComponent> 

The XCL Component Declaration identifies the XML construct as an XCL component 
1 0 definition and associates It with a XCL Name. The Declaration contains an instance of a 
Component Signature and an instance of a Component Body. 

Component Signature 
<xcl:Component name- green'> 
1 5 <xcl:Parameter name='marsaiis' /> 
<xcl:Publish name='fuller* /> 
<xcl:Subscribe name^'evans' /> 
</xcl;Component> 

The Component signature defines the encapsulation of the component Scope. This is 
20 done through zero or more instances of a Component Parameter and zero or more instances of 
Publish/Sul)scribe Parameter. This signature defines the type' of the XCL component The return 
type of a XCL Component is always assumed to be a Iragment of well formed XML. 

Component Parameter 

25 <xcl:Parameter name='tyner'> 

... optional default parameter data ... 
</xcl:Parametfir> 

Parameters are the way that data is passed Into the functional scope of a given 
component They have a XCL Name and a some possible contained XML that becomes the 
30 defeult assignment for that Parameters. 

Component Body 

<xcl:Body> 

... component executable content ... 
35 <xcl:Body> 

The Component body Includes executable content v^o's exact form Is specific to a 
particular Component Kind 

Inline Component 
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It is also possible to directly specify a component 'in-line' to another component Strictly 
speaking this mode is triggered by the inclusion of an Annotation Body in and XCL Annotation. 
This means that the component's annotation is not separated from the components Component 
Definition. 

5 

XCL Library 

<xci:Ubrary> 

... identity ... 

... authoring properties ... 
10 ... one or more component definitions , .. 

</xcl:Library> 

Any given Components is placed into exactly one XCL Library. It has a identity, a set of 
authoring properties, 

15 Library Identity 

<ProcessHX)ntainer:VURL> 

... URL defining identity and location of library ... 
</Process-contalner: VU RL> 

Since a XCL Library is a standard Process-container Resource, it is identified by a 
20 standard Resource VURL. 



Library Authoring Properties 
<xcl:Author> 

... name of author responsible for library ., 
25 </xcl:Author> 



XCL Annotation 

Once an XCL XCL Component is defined, it can be called within the Component 

Body of another XCL component (at least those who have XML as executable con-tent 
30 These functional calls are invoked through the use of Annotations. These invocations are 

proxies that represent a later substitution of the XML of the actual Annotation with the XML that 

is the result of the functional component call For Instance one call of each Annotation Kind (on 

page 84), Is shown below: 

<bfakey> 
35 <xcl:Rule name=*morgan' /> 

<xcl:Swatch name='basie' i> 

<xcl:Transfomi name=*eIllngton' /> 

<xcl:Query name=*strayhom' > 

</blakey> 
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Annotation Declaration 

<xchSwatch name='vituous'> 
... swatch definition ... 
5 </xcl:Swatch> 

<xcl:Rule name='pederson'> 
... rule definition ... 
<;/xcl:Annotatlon> 
<xcl:Transform name='fbrtune'> 
10 ... transform definition ... 
</xcl:Transform> 
<xcl:Query name='tyner'> 
... query definition ... 
<A(ci:Query> 

1 5 The XCL Annotation Declaration identifies the XML construct as an XCL Annotation 

definftion and associates It with a XCL Name and possible an attribute to specify the XCL 
Library. The Declaration contains an instance of a Annotation Signature and a possible instance 
of a Annotation Body. 

20 Annotation Signature 

<xcl:Swatch names'dolphy'> 

<xcl:Paranrjeter nanie='marsa!ls' l> 
<xcl: Publish names'fullef /> 
<xcl:Subscribe name='evans' /> 
25 <xcl:Swatch> 

The Annotation signature Instantiates the data and events passing Into the Annotation 
Scope. This is done through zero or more instances of a Annotation Parameter and zero or more 
instances of Publish/Subscribe Parameter. This signature defines the type' of the XCL 
Annotation. 

30 

Annotation Parameter 

<xGi:Parameter name="> 

... optional default parameter data ... 
</xcl:ParametBr> 

35 Parameters are the way that data Is passed into the functional scope of a given Annotation. They 
have a XCL Name and a some possible contained XML that becomes the default assignment for 
that Parameter. 

Annotation Body 
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<xct:Body> 

... Annotation executable content ... 
<xcl:Body> 

The Annotation body includes specific executable content whose exact form Is specific to 
5 a particular Component Kind, By putting a Body into the Annotation we create some-thing 
called an Inline Component. 

Annotation Kind 

TTiere are four Idnds of Annotations, one for each Component Kind. 

10 

Annotation execution 

The Invocation of a annotation is not exactly lilce traditional functions is in how and when 
they are executed. Instead of being executed procedurally, they are executed either during 
acth/ation or after scheduXng, 

15 

Activation 

Activation Is where the annotation is set up for execution and also where it is executed. 
XCL Scope 

20 Tuming to FIG. 35, the XCL execution logic takes the XCL source and uses it to build a 

set of scopes at nin-time. These scopes are very similar to stacic frames in a standard 
procedural language except that they are organized Into trees. These trees are actually bunt and 
modified at run-tfme as XCL annotations are brought Into scope, executed 

25 Static Scopes 

The first part of Scoping within XCL is defined statically. This means that it is defined by 
the nature of the way that component definitions call other components In the same or a different 
XCL Library. 

The Library Scope supports access to a set of XCL Variable instances associated with 
30 the current XCL Library that this XCL was defined within. The Component Scope supports 

access to a set of XCL Variable Instances associated with the cun^ntXCL Component of which 
this XCL is part. 

Dynamic Scope 

35 Tuming to FIG. 37, the second part of Scoping within XCL Is defined dynamically. These 

scopes are defined by the run-tlme environment set up to provide a context for the static scopes. 
Dynamic Scopes are mostly used to access the properties of a mn-time aspect of the executing 
XCL. The following dynamic scopes are introduced: 
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• Engine Scope: The Engine Scope supports access to a set of XCL Variable instances 
associated with the current Process-container Engine that this XCL is executing on. 

• Process-container Scope: The Process-container Scope supports access to a set of XCL 

Variable instances assodated with the current Process-container that this XCL Is executing in. 
5 • Page Scope: The Page Scope supports access to a set of XCL Variable Instances associated 
with the current Page Context that this XCL Is executing in. 

• Window Scope: The Window Scope supports access to a set of XCL Variable instances 
associated with the current XCL Window that this XCL is executing in. 

• Frame Scope: The Frame Scope supports access to a set of XCL Variable instances 
1 0 associated with the current XCL Frame that this XCL Is executing in. 

XCL Event 

As part of the basic contracts within the XCL environment is the concept of events. Because the 
XCL environment is based on event driven re-evaluating functional components, understanding 
1 5 sourdng and sinking and general flow of events is a critical aspect of understanding XCL. 
Named-event 

There is basic fonn of events in XCL Is the XCL named-everii Theses named events can be 
sourced and sinked within the XCL environment 
Event data 

20 Named-events can have data associated with them. This data is expressed as fragments of well 
fornied XML 
Browser event source 

XCL supports the concept of browser-event sources on all/most? HTML tags. These are the 
standard DOM HTML events that are used by javascript in HTML. The browser events that can 
25 be sun k from a given HTML element follows the W3C DOM level 2 Javascript bindings. Examples 
are: onCIIck, onSelect, and onChange. Browser-events do not actually broadcast within the 
component scope like named-events do. In fact, before they can propagate with a component 
scope, browser events must be 'mapped' by a event-map construct. This special xcl sventMap 
attribute tooks like: 

30 <SOMEHTMLELEMENT xcl:eventMap='someBrowserEv6nt:someNamedEvent;' /> 

The constmct above take the HTML element 'SOMEHTMLELEMENF and translates a browser- 
event source 'someBrowserEvenf to a broadcast, to all event-sinks within the current component 
scope, of tiie named-event 'someNamed Event'. 

Some browser-event have associated data. This associated data is In the form of a string. For 
35 instance the onChange browser event has the new string value of the associated HTML element 

Event Sources and Sinks 

Turning to FIG. 37, there are both Bvera-sources and event-sinks within the XCL 
environment Events by definition flow from event sources to event sinks. 
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Scope level broadcast 

Turning to FIG. 38, any named-event source within the encapsulated scope of a 
Component broadcasts ail of its events to all matching named event stnlts within that 
5 encapsulated scope. 

Event encapsulation 

Turning to FIG. 39. all flow of named-events is controlled by the encapsulation of the 
component scope. The broadcast of a named-event from a given source is by default stopped at 
10 the component scope boundaries. 

Publish/Subscribe Parameter 

Turning to FIG. 40, In order to puncture the component scope boundary, two special 
types of parameters called publish and subscribe need to be used. 

15 

Publish Variable 

Publish parameters allow events to be pushed from the current component scope 
outward to its containing component scope. 
<xcl:Publish name='dizzy' trigger='mingus'> 
20 ... publish data ... 

</xcl:Publish> 

Subscribe Variable 

Subscribe parameters allow events to be pulled firom the containing scope component 
25 into the current component scope. 

<xcl:Subscribe name='mlngus' trigger='dizzy' > 

... subscribe default ... 
</xci:Subscribe> 

30 Subscribe propagation 

<xcl:Subscribe name^'hawkins' trigger^'webster' 

propagate='parent|local|both' > 

... subscribe default ... 
</xcl:Subsaibe> 

35 

Subscribe parameters have an attribute called 'propagate' that can be set to 
'parent ;iocar or 'both'. If it is not provided, then the default value is 'parerA!. The semantics of 
these options are: 

• parent: the event Is propagated only to the parent component scope 
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• local: the event is only propagated within the current local component scope. 

• both: the event is propagated to both the local and parent component scopes. 

Publish subscribe data 
5 Publish and subscribe parameters can have data contained within them or not. If a 

publish parameter contains data, then the name-event will have that data attached to it when it is 
published. If the subscribe parameter has data attached to it, then this will be used as the de^ult 
value until a new name-event triggers it 

10 Articles 

Turning to FIG. 41 , publish subscribe variables can also be used to publish what are 
called 'articles'. Tliese are page global events that can be subscribed to by any component 
scope. 

<xci:Subscribe name-'mlngus' trigger^'dizz/ artlcle='PageLevelEvent> 
15 ... subscribe default ... 

'^cl:Subscribe> 



Publish Subscribe filtering 

<xcl:Subscribe name='<expr1>' trigger='<expr2>' article='<expr3>'> 
20 ... subscribe default data ... 

</xcl:Subscrlbe> 

<xcl:PubIish name='<expr4>' triggers'<expr6>* article='<expr6>'> 

... publish data attachment ... 
</xcl:Publlsh> 

25 All publish and subscribe parameters can have their names, trigger, and article attribute 

values specified as a regular-expression. This regular-expression Is used to specify a filtering 
mechanism that allows a set of named-event names to be selected based on matching the 
regular expression supplied. The following are examples: 

30 Subscribe name filtering 

Filtering can be used to support the subscription of groups of named-events through the 
component scope boundary without having to specify each one Individually. Setting the name 
attribute to the all inclusive match '*', tells the event system to pass whatever events are in 
trigger attribute as the same named event. It is only legal to have one name, or a in the name 
35 attribute value. 

<xcl:Subscribe name='*|name' trlgger=*<expr1>' > 

... publish data attachment ... 
</xcl:Subscribe> 
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Subscribe trigger filtering 

Filtering can be used to support the publishing of gnjups of trigger named-events 
through the component scope boundary without having to specify each one Individually. Setting 
the name attribute to the all inclusive match '*', tells the event system to pass whatever events 
5 are In trigger attribute as the same named event. It is only legal to have one name, or a **' In the 
name attribute value. 

<xcl:Publish name=**Iname' trigger='<expr1>* > 

... publish data attachment ... 
</XcI:Publlsh> 

10 

XCL Variable 

<xcl:Variable name='hendrix'> 
... variable content ... 
<A(cl:Variable> 

1 5 XCL supports a construct called a Variable. This allows the arbitrary constmcQon of data 

containers that can be referenced by name during XCL execution. 

Variable Names and References 

Shendrix. 

20 Each Variable has an attribute that is an XCL Name. This name supports access to the 

Variable's content in an instance of a XCL Expression using a Variable Reference. 

Variable Content 

Each Variable potentially has some sort of Content expressed within iL If it has no 
25 content, then the content is assigned to be NULL. Otherwise any well fonfned XML fragment can 
be placed into Variable including plain text 

Variable Scoping 

Refening to FIG. 42. variables represent a data access method that brealcs the 
30 Component encapsulation. 

XCL Expression 

XCL supports the evaluation of the an XCL expression placed Into either attribute or 
element content. This expression is a combination of a possible root variable reference, and an 
35 XPATH expression with possible Variable References 

Expression syntax 

root-expression:: 

{rootvariable} expression 
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expression:: 

{xpathKvariable} 
variable:: 

'$• identifier 

5 The XCL expression syntax is shown above. 



Expression Evaluation 

The XCL expression when evaluated returns zero or more XML nodes. This definition 
inciudes the possibiDty of retunning: nothhg, plain text, comments, attributes, and elements. 

10 

Attribute Expression 

<element attribute1='root-expression* t> 

An attribute expression is an xcl expression that is inserted into an XML attribute. The 
only acceptable types of return for this form of expression are: nothing and plain texL 

16 

Element Expression 

<elenien> root-expression </element> 

An element expression is an xcl expression that is Inserted Into an XML element. All 
possible return types are supported. 

20 

Where are expressions evaluated 

Expressions cannot be placed into any attribute or element Only certain attributes and 
elements within the XCL Source Language. It would illogical to have some elements or attributes 
contain expressions because the syntax of the expression could not be distinguished from 
25 normal plain text 



Forced evaluation 

<xcl:element evaluate='truelfalse' > possible expression </xcl:element> 
<element xcl:evaluate=true|false' > possible expression </element> 
30 XCL supports a special attribute called 'xcl:evaluate' that force the evaluation of the 

contents of an element If the element Is In the XCL namespace, then the 'evaluate' attribute 
name Is used Instead. 

Variable Reference 
35 variable:: 

'$' Identifier. 93 



An XCL expression can be solely a variable reference, or can have variable references 
intermixed anywhere within the expression. 
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Root Variable Reference 

An XCL expression usually has to be started by a variable reference. 

5 Resource Root 

There can be support for the ability to specify a VURL at the beginning of an XCL 
expression. This would start the XPATH at the docunfient element of the XML resource identified 
by that VURL 

10 XPATH 

The full Xalan XSLT/XPATH expression language is supported within the text of an XCL 
expression. 

XCLSwIzzling 

15 Like It is for the XCL Expression, much oftheXCL Source Language, can have various 

attributes or elements 'swizzted*. This means that the contents of that attribute or element is 
assumed to be in the fbnn of a Resource VURL. At run-time this VURL is replaced with a 
Resource PURL. 

20 XCL Query 

Queries are XCL components that support the execution of XPATH queries. 
Query Component 

<xcl:QueryComponent name=1dentlfler1'> 
25 ...signature... 

... Query Body ... 
</xcl iQuery Component> 

A Query Component includes a Component Signature, and a Query Body. 

30 Query Body 

The Query Body contains a XPath expression to be either as a Resource Query or a 
Context Query. 

Resource Query 

<xcl:QueryComponent name='identlfler1' resource='VURL' > 

The Resource Query is where a Process-container Transaction, Is the root of the XPATH 

query. 

Context Query 
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<xci:QueryComponent name-'identifieii' context^'xclExpressbn' > 

The Context Query is where an XCL expression is the root of the XPATH query. 



Query Annotation 
5 <xcl:Query name='identifier1'> 

...signature instantiation... 

... optional inline QUery Body ... 
s</xcl.-Query> 

Queries are executed through the Annotation syntax. They may include an Instantiated 
10 Component Signature, and a potential inline Query Body. 

Simple inline Queries 

<xcl:Query context^^'xclExpression' > 

..jcpath expression... 
</x<A:Qiiery> 

<xci:Quefy resource= VURL' > 

..jcpath expression... 
</xcl:Query> 

Because this construct is so important for many XCL programming tasics, a very simple 
'syntactic sugar* version of the Inline query is defined. 

XCL Rule 

Rules are XCL components that support the execution of ECMAscript O'avascrlpt}. 
Rule Component 

<xcl:RuieComponent name='identifier1 *> 
...signature... 
... Rule Body ... 
</xci:RuleComponent> 

A Rule Component includes a Component Signature, and a Rule Body 

Rule Body 

<xcl:Body name='identifier1'> 

... ECMAScript source ... 
35 </xci:Body> 

The Rule Body Is assumed to be In the fomi of a standard JavaScript function body. 
However since the Rule Component defines the parameters, the body does not need the: 
function(parameter, parameter, parameter) { 

..rule semantics... 
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} 

Form. Just intra-function aile semantics themselves are included. 

Rule Annotation 
5 <xcl:Rulename='identifier1*> 

...signature Instantiation... 
... optional inline Rule Body ... 
</xcl:Rule> 

Queries are executed through the Annotation syntax. They include an instantiated 
10 Component Signature, and a potential inline Rule Body. 

XCL Transform 

Turning to FIG. 43, transforms are XCL components that support the execution of XSLT 
standard 'transforms'. These transfomns take an XSLT transform Body, a special Source 
15 parameter that contains arbitrary XML, and then using an XSLT processing engine creates a 
XML fragment that is the result of the transform process. 

Transform Component 
<xcl:TransformComponent name='identifier1 '> 
20 ...signature... 

...XSLT Body ... 
</xcl:TransformComponent> 

A Transform Component includes a Component Signature, including a special 
25 Source Parameter, and a Transform Body. 
Source Parameter 
<xci:Parameter name='source'> 

There Is a predefined parameter in each Transform, that represents the source. 
Transform Body 

30 The Transfonn Body contains an XSLT style sheet minus the enclosing; 
<xsl:stylesheet> 

tag. This Transform Body can contain XCL elements along with other XML elements. These 
elements wi!l be executed. 
Transform Annotation 
35 <xcl:Rulename='ldentifier1'> 

...signature Instantiation... 

... optional inline XSLT Body ... 
</xcl:Rule> 
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Queries are executed through the Annotation syntax. They indude an instantiated Component 
Signature, and a potential inline Transfonm Body. 
XCL Swatch 

The XCL swatch represents a an arbitrary parameterized XML fragment. 
5 Swatch Component 

<xcl:SwatchComponent name='identifier1'> 

...signature... 

... Swatch Body ... 
</)ccl:SwatchComponent> 

10 . 

Swatch Body 

<xcl:Body name='identrfier1'> 

... arbitrary XML ... 
</)(cl:Body> 

1 5 The Swatch Body is assumed to be any well formed XML fragment. 97 

Swatch Annotation 

<xcl:Rule name='ldentlfier1'> 

...signature Instantiation... 
20 ... optional inline Swatch Body ... 

</xd:Rule> 

Swatches are executed through the Annotation syntax. They Indude an instantiated Component 
Signature, and a potential inline Swatch Body. 

25 XCL White Space 

XML Is a language that by default treats white-space as non-lgnorab!e. This is called 
white-space preservation. XCL libraries are space preserving. They are also designed to be 
supportive of readable code. That means when a construct lilce: 
<xci:Variable name='coitrane'> 
30 This is some text 

</xd:Variable> 

is parsed, the variable 'coltrane' does not contain the string: 

"This is some texT 
but rather contains: 
35 "\n\1This Is some textVi" 

if you want It to contain the fonmer string you would have to write: 
<xcl:Variab!e name»'coltrane'>This is some text</xd:Variable> 
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This is very appropriate beiiavior for XML as It is not at all obvious when white space is a 'read- 
ability' artifact or a 'content' artifact. This does not ioolc that bad. (However if you make a more 
complex potentially deeply nested statement such as: 
<xci:Swatch name='coitrane'> 
5 <xc!:Parameter name='miles'/> 

<xcl:Rule name-'corea'> 

<xcl:Parameter name=*byrd'> 

this is a long line that needs no white space at either end 
<ft(Ci:Parameter> 
10 </xcl:Rule> 
</xcl:Parameter> 
</xcl:Swatch> 

Then it might be very important to be allowed to 'readability' white space liberally without having 
it effect content To make it even more trick, any given XCL construct can be sensitive or not to 
1 5 white-space depending on what it is. For instance the XCL snippet: 
<xcI:SwatchComponent name='dizzy'> 
<xcl:Variable names'miles'> 

<data> Ikjhsdljg <data> 
</xcl:Variabie> 
20 <xcl:Swatch> 

Does not care about white-space between the swatch annotation 'dizzy' and the variable 'miles'. 

Ideally control over how XCL treats white space within its libraries is desired. This Is indeed 

possible and the applicable construct looks Dke the following: 

<xclK^nstmct1 trlm='cabv'> 
25 <xcl:Construct2 trim='cabv'/> 

<yxcl:Construct1> 

or the following: 

<xcl:Construct1 trlm='cabv'> 

<nonxcl:Construct2 xcl1rim='cabv'> 
30 </xci:Constnjct1> 

Note that in the first form, the Inner construct2 since it Is an XCL construct, used the default 

namespace meaning that the 'trim' attribute name is used. In the latter form where the inner 

construct2 is not an XCL construct, the fully qualified *xcl:trjm' attribute name is used. The 

semantics of this construct are divided into four mies of which any or all can be applied by adding 
35 the appropriate letter to the attribute value in any order. 

Content Trimming Rule 

The first semantic rule is enabled when the letter 'c' or'C are extent in the trim attribute value. 
This rule Is called content trimming. This means that for the applicable construct, the ignorable 
white space on either end of the XMl contained within it is trimmed. An example of this is: 



•49- 



wo 02/05106 



PCT/USOl/21462 



<xcl:Variable name^'lioner trim='c'> 

<el/> 
</xcl:Construct1> 

which after processing would be equivalent to writing: 
5 <xcl:Variable name='lione)*><e1/></xcl:Variabte> 
which many would say is more readable. 
Before Trimming Rule 

The second semantic rule is enabled when the letter 'b' or 'B' are extent In the trim attribute 
value. This rule is called before trimming. This means that for the applicable construct, the 
1 0 ignoFabie white space before It Is trimmed. An example of this Is: 
<xci:Variable name='cannonbait'> 

<xcl:Rute trim='b'> 
</xcl:Construct1> 

which alter processing would be equivalent to writing: 
15 <xci:Variable name='lioner><xcl:Rule/> 
</xcl:Variable> 
After Trimming Rule 

The third semantic rule is enabled when the letter *a' or'A' are extent in the trim attribute value. 
This rule is called after trimming. This means that for the applicable construct, the Ignorabie white 
20 space after it is trimmed. An example of this Is: 
<xcl:Variable name='cannonbaD'> 

<xcl:Rule trim=*a'> 
</xcl:Construct1> 

which after processing would be equivalent to writing: 
25 <xci:Variable name='lloner> 

<xcl:Rule/></xcl:Variable> 
Value Trimming Rule 

The fourth semantic rule is enabled when the letter 'v' or V are extent In the trim attribute value. 
This rule Is called after trimming. This means that for the applicable construct, the Ignorabie white 
30 space after it is trimmed. An example of this Is: 
<xcl:Variable name«'cannonbaII'> 

<xcl:Rule trim='a'/> 
</xcl:Construct1> 

which after processing would be equivalent to writing: 
35 <xcl:Variable name='lioner> 

<xcl:Ruid/><A(d:Variable>. 
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9. XCLUser Interface 

The XCL API has a set of language constructs and run-time mechanisms that support 
the ability to write thin client user interfaces wHh full support from a unique XML based 
component language. 
5 XCL Widget 

XCL supports Its own form of Widgets which are defined to be visual elements that 
support the display of, and interaction with, scalar data. There are actually only three base 
primitives: TextField Widget, Editor Widget, and Select Widget. There are however several 
derived syntactic sugar versions of the above: Button Widget and Checl<box Widget The 
1 0 syntactic sugar versions are literally subtypes of the t^ase primitives. 

Binding Clause 

<xcl:Blnding> 

<xcl:Query resource="http:y/www.lnfocanvas.com/Process-container/data.xml"> 
15 //playsBass 
<yxcI:Query> 
</xcl:Binding> 

Common to all widgets is a binding clause. This clause establishes the data source and sinic for 

the widget. 
20 Sinic and Source binding 

Bindings are used to express data-source and data-sink behaviors. Data-source 

behaviors are where the associated Widget gets it's visualized value from. Data-sink behaviors 

are where interactive updates to the visualized widget are used to update some XML nodes 

somewhere. 
25 Query Bindings 

If the interior of Binding clause is an XCL query, then special sink and source behaviors 

are provided. The query binding is bidirectional meaning that the widget is initialized to the result 

of the query, and any updates to the widget are directed back to the nodes representing the 

results of the query. The widget will be visually updated any time the query is executed. 
30 Non-query Bindings 

If the Interior of Binding clause is an not an XCL query, then only source behaviors are 

provided. In this case, the widget is always initialized to the interior of its binding. The widget wili 

be visually updated any time the Interior XCL is executed. 

TextField Widget 
35 <xcl:TextField> 

<xcl:Binding> ...xcl... </xcl:Binding> 

<;xcl:TextField> 

The TextField widget is used to allow one-line text field text editing. 
Edhor Widget 
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<xcl:Editor> 

<xct:Binding> ...xci... </xcl:Binding> 
</xcl:Editor> 

The Editor widget is used to allow multi-line text or html marloip editing. 

5 

Select Widget 
<xcl:Setect 

metaphors''buttongroupill6tbox|dropdown" 
selectlon="s]ngle|multiple'' > 
10 <xcl:Bindlng> ...binding... </xcl:Binding> 

<xcl:AGtionSet> ...actions... </xcl:ActionSet> 

</xcl:Select> 

The Select widget is the way that XCL models a visualized set of choices and allows 
data binding and expressive data sink flexibility. At the top level a Select includes a binding and 
15 anAdionSet. 
Selection Mode 

Select widgets have the option to allow single or multiple selection modes. Single Select 
mode means that within the Actions clause only the result of a single Action can be enabled at 
one time. In the multiple mode, more than one action can be enabled simultaneously. 
20 Selection Metaphor 

The Select widget has a number of selection metaphors. These metaphors define how a 
set of actions are visualized. 

• buttongroup: A set of actions that are visualized as buttons. 

* listbox: A set of actions that are visualized as a iistbox. 

25 • dropdown: A set of actions that are visualized as a dropdown. 
ActionSet 
<xcl:ActionSet> 

...combination of actions, labels, and HTML markup... 
</^cl:Actk>nSet> 

30 An ActionSet is a clause that contains Actions, Labels, and potentially HTML markup. It 

defines the actions that a Select provides along with directh/es about associated visual cueing 
and organization. 
Action 

<xcl:Actlon metaphor="checkbox|radiobutton limage'^ 
35 ...values associated with various states of the action... 

</xcl:Action> 

A Widget Actk>n Is a combination of the following: a visual cue of a particular metaphor 
for a specific interaction option in the select and/or a Value or set of Values associated with 
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various states in the Action. Ttiese together represent an action that a user can 'choose' to talce, 
the visual changes associated 

with choosing that action, and the resultant updates to the bound data. 
ActionState 

5 <xcl:ActionState state='sf8fe'> 

...update value associated with this state... 
</xcl:AdionState> 
<xcl: ActionState state= 'sfafe'> 

...update value associated with this state... 
10 </xcl:ActionState> 

The ActionState clause is designed to associate different visual and update values with 
different states that an Action can be in. These states have well defined default and specifiable 
behaviors. Each Action can be assumed to be in exactly one of Its States at a time. The value 
associated with a State, can be any sort of XML fragment, including plain text (a common mode 
1 5 for simpie select scenarios). 
ActionState State 

Each ActionState has either an fmplidt or exp//cf/ state associated with it. If these states 
are explicit then there is an attribute called 'stats' associated with it that detenrnines this state 
value. If the state is impJIcnth&n default values are assumed based on the document ordering of 

20 the particular ActionState within the parent Action. The set of appropriatG state values for a set 
of ActionState Instances within an Action can be specified in a number of ways: a contiguous 
integer set starting from 0 and going to a number N that specified the order of ActionState 
instances to be visually cued and/or as a set of identifiers associated with the states of a given 
Action metaphor. 

25 Action metaphor 

Each action has a me/ap/7or associated with it. This controls both interaction and 
ActionState semantics for the Action. The cun-ent set of metaphors Is: 

• checkbox: a HTML checld)ox is displayed. There are exactly two possible states, the first state 
being visually cued as unchecked, the second state as c/)ec^ed. As a default if no ActionState 

30 clauses are inserted the update bindings will be false* and true' respectively. 

• image: a set of HTML images are displayed. There are an unlimited number of states 
associated with an unlimited number images. This is used to do the 'mulUstate button'. 

• radiobutton: a HTML radiobutton is displayed. There are exactly two possible states, the first 
state being visually cued as enabled, the second state as disabled. Action states are specified to 

35 determine the update values. 

Label 

<!- miimiiimmiminnttmtntimmmmmmi -> 

<]- label associate with an ActionState -> 
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<!- inimiiwmimiiimwmmminmmtm -> 

<xd:ActionState> 
<xcl:Labe> 

<img src=' Jimages/false.gif/> 
5 </xcllabel> 

...update value... 
<A(cl:AcUonState> 

<i- nnmmmmmmmummummmmuum -> 

<1- label associate with an Action -> 

10 <!> miimuimmmmmmmwmmmmmiM 

<xcl:Action> 

<xcl:Label>guitar</xcl:Label> 
<xcl:ActionState>...update value.. .</xcl:ActionState> 
<xc):ActionState>...updatevalue...</xcl:ActionState> 
15 </xd:Actlon> 

To support Select clauses, a Label clause is provided. This clause informs the Select clause that 
some sort of label is associated with an Action or an ActionState. 
ActionSet XML markup 

<xcl:ActionSet> 
20 <table> 

<tr> 

<td> 

<xcl:Action> 

<xcl:AcllonState> 

25 <bass selected="true"></bass> 

</xcl:ActionState> 
<xcl:ActionState> 

<bass seiected="folse"></bass> 
</xci:ActionState> 
30 </xcl:Action> 

</td> 
<d> 

<xci:Action metaphor=''radioButton"> 
<xd:ActionState> 

35 <guitar selected=1rue'^</gultar> 

</xcl:ActlonState> 
<xd:ActlonState> 

<guitar selecited='1alse"x/guitar> 
<xcl:ActionState> 
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</xcl:Acaon> 

<m> 

<td> 

<xcl:Act}on metaphor="radloButton''> 
5 <xcl:ActionState> 

<drums selected=''true"></drums> 
</xcl:ActionState> 
<xcl-^ctionState> 

<dnjms selected='Yalse''><ydnjms> 
10 </xcl:ActtonState> 

</xcl:Action> 

</td> 

</tr> 

</table> 
15 </xcl:ActionSet> 

ActionSets support the concept of Intermixed XML markup including HTML and XCL 
elements. This nnode is supported for the select tultongroup' metaphor. With advances in 
HTML or in the Browser Model this mode may be supported for other metaphors. 
Button Widget 
20 <xcl:Button eventMap="/)row5er£v©nt:/7afned-evem;"> 
dick here 
</xcl:Button> 

<xcl:Button 6ventMap="/irowser£ve/}t:iiamed-«vent:'^ 
<img src^'ImageURL' t> 
25 </xcl:Button> 

The XCL button is actually a syntactic sugar version of one particular Select clause 
scenario. It presents the enclosed HTML that when actuated (receives a user stimulus), sources 
a Named-event via the Browser event source eventMap clause. 
Checkbox Widget 
30 <xcl:Checkbox>. 

<xcl:Query resource="http:/Avww.in1bcanvas.com/Process-container/dataj(mr^ 

//playsBass 
</xcl:Query> 
</xcI:Checkbox> 

35 The XCL checkbox Is also a syntactic sugar version of one particular Select Vindget scenario. 
XCL Collection 

Turning to FIG. 44, collections are XCL user interface constructs that support the visual 
presentation and interaction with XML node sets. These are usually the result of XCL queries 
that return more than one result node, but can easily contain any fbnm of XML. 
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<xcl:Collection> 

<xcl:Binding>... some data-source/data-sink... <xcl:Binding> 
<xcl:Laydut>... some layout XCL... </xcl:Layout> 
<xd:Rows>2</xcl:Rows> 
5 </xcI:Collection> 
Data Binding 
<xcl:Binding> 

<xcI:Query oonlext="empioyees"> 
employees/employee 
10 </xcl^luefy> 
<xcI:Bindlng> 

The Binding clause in a Collection constnjct is used to bind the collection to some data. 
Usually this is a query, in which case special events are handled to support updates, or this is 
some other arbitrary XCL in which case, the Data Binding Is only to support the data-source 
1 5 binding for this collection. In this latter case, it is presumed that the data^lnk or update binding is 
either not necessary or supported In custom manners. 

Layout 

<xcl:Layout> 

20 <xd:Transform name="emptoyeeTransfonn" /> 

</xcl:Layout> 

Special Collection Events 

• xci:query:movefirst: subscribe to xcl:query:movetirst allows query catch the move first event 
25 fired by the collection tool bar. 

• xcl:query:movelast: subscribe to xcl:query:movelast allows query catch the move last event 
fired by the collection tool bar. 

• xcl:query:moveprevious:subscribe to xcl:query:moveprevious allows query catch the move 
previous event fired by the collection tool bar. 

30 • xc]:query:movenext: subscribe to xcl:query:movenext allows query catch the move next event 
fired by the collection tool bar. 

■ xci:query:deiete: subscribe to xcl:query:delete allow querys catch the delete event fired by the 

collection tool bar. 

• xci;query:insert: subscribe to xcl:query:lnsert allow querys catch the Insert event fired by the 
35 collection tool bar. 

- xcl: query mextpage: subscribe to xcliqueryrnextpage allow querys catch the next page event 
fired by the collection tool bar. 

• xcl:query:previouspage: subscribe to xcl:query:previouspage allow querys catch the previous 
page event fired by the collection tool bar. 
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XCL Style 

The XCL language supports the use of Presentation Styles based on standard 
Cascading Style Sheets (CSS). 
XCL Navigate 

5 <xcl:Navigate trlgger='named-event-llst' frame='ldentlfier' > 
...XCL to place into the identified frame... 
</xcl:Navigate> 



<xcl:Navlgate triggeR'named-event-lisf windovkp'identifier' >. 10g 
10 ...XCL to place into the Identified window... 

</xd:Navlgate> 

The XCL language supports a special form of Anchor called a Navigate, that acts mostly 
lil<e an anchor but has special semantics for the Process-container Environment. 



15 XCL Window 

<xcl:Window name=*ldentlfler* > 

...more XCL but In a different window... 
</xcl:Window> 

The XCL language supports the use HTML Windows, with special semantics for the 
20 Process-container Environment 



XCL Frame 

<xci:Frame name='identifier' > 

...more XCL but In a different frame... 
25 <Accl:Frame> 

The XCL language supports the use standard HTML Frames, with special semantics for 
the Process-container Environment. 

Widget Examples 
30 Below are a series of example of using widgets In XCL. 

Labeled Button 

<xcl:Button eventMap»"onClick:myRule:''> 

click here 
</kcl:Button> 

35 This button provides a clickable text label. 

Image Button 

<xcl:Button eventMap="onClick:myRule;"> 
<img sr(F'../images/niyButtonGir> 
<A(Cl:Button> 
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This button provides a clickable image. 
TextField 

<xcI:TextField> 

<xcl:Binding> 

<xcl:Query resourc8="http://www.infocanvas .comyProcess-contalner/data.xmr> 

//playsBass 
•</xcl:Query> 
</xcl:Blnding> 
</xcl:TextFleld> 

This button provides a an editable text field that Is input and output bound to a query. 
Text Field with Event mapping 
<xcl:TextField eventMap="onBeforeUnIoad;"> 

<xcl:Blnding> 

<xcl:Query resource="http://www.infocanvas.com/Process-container/data.xmI"> 

//playsBass 
<M:Query> 
</xcl:Bindlng> 
</xcl:TextField> 

This button provides a an editable text field that is Input and output bound to a query but 
the update is only applied when the onBeforeUnload event is fired in the browser. 
Stateless Button 

<xcl:Select metaphor='*buttonGroup* selectlon=''$tateiess"> 
<xcl:ActionSet> 

<8pan style="style1*>dick here to do tiie right thing 

<xcl:ActloneventMap="onClickaomeRule'*></xcl:/Vction> 

</span> 

</xcl:AGtionSet> 
</xGl:Select> 

This select statement models a stateless button. 
TriState Buttom 

<xcl:Select metaphor="buttonGroup" selection="muItr> 
<xcl:Blnding> 

<xcl:Query resource="http://vvww.lnfocanvas.com/Process-container/data.xml''> 

//playsBass 
</xcl:Query> 
</»«l:Binding> 
<xd:ActionSet> 

<xcl:Action metaphor="cu5tom'^ 
<xcl:ActionState> 
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<xcl:Label> 

<img src='.JImages/lrue.gir/> 
</xcl:Label> 

<bass se)ected="true"><ybass> 
5 </xcl:ActionState> 

<xcl:ActionState> 
<xcl:Lab8l> 

<img src=\Jimages/false.gif /> 
</xcl:Labe> 

10 • <bass selected="false"></bass> 

</xcl:ActionState> 
<xcl:ActionState> 

<xcl:Label type="gir> 

<img src- .Jimages/maybe.gif > 
15 </xd:Labe> 

<ba8s selecled=''maybe"></bass> 
</xcl:ActlonState> 
</xcl:Action> 
</xcl:ActionSet> 
20 </xct:Select> 

This select statement modeis a tri-state button. This means that the button has a series 
of states that it can be cycled through, each with its own image to represent it and an update to 
the binding query of three diffierent values. 
Checkbox with custom states 
25 <xcl:Select metaphor='T3utlonGroup" selection="singIe"> 

<xcl:Binding> 

<xcI:Queryresourc8="http:/AflflAwjnfocanvas.com/Process-container/dala.xml"> 

//piaysBass 
<A{Cl:Query> 
30 </xcl:Blnding> 
<xci:ActionSet> 

<xcl:Actlon metaphor«"checkbox"> 
<xcl:ActionState> 

<bass selected="true"></bass> 
35 </xcl:ActtonState> 

<xcl:ActionState> 

<bass selected="false"x/bass> , 
</xcl:ActionState> 
</xcl:Action> 
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</xcl:ActionSet> 
</xcl:SeIect> 

This select statement models a complex checkbox with two custom defined stales. 
Checkbox (syntactic sugar version) 
5 <xcI:CheckbQx> 

<xcl:Query resource="hitp:/AAww.infocanvas.com/PrGcess-container/datajcml"> 

//playsBass 
<Accl:Query> 
<A(cl:Checkbox> 

10 This checkbox is actually a form of select with syntactic sugar to make it easier to write. 

The binding is updated with true/false. 
Select DropDown 
<xcl:Select metaphor^'dropdown^ 
<xcl:B(nding> 

15 <xcl:Query resouroe="http://www.infocanvas.com/Proces8-conlainer/data.xml'^ 

//instrumentPlayed 
</xcl:Query> 
</xcl:Bindlng> 
<xcl:ActlonSet> 
20 <xcl:Action> 

<xcl:Labe>bass</xcl:Label> 
<xc|-J\ctionState> 

<bass seiected="true'></ijass> 
</xcl:ActionState> 
25 <xcl:ActionState> 

<bass selected="fdlse"><>bass> 
</xcl:ActionStatB>' 
</xcl:Action> 
<xcl.Action> 

30 <xcl:Label>guitar</xcl:Label> 

<xd:ActionState> 

<guitar selected="true"></gultar> 
</xcl:ActionState> 
<xcl:ActionState> 

35 <guitar 8elected='Talse'^</gultar> 

</xd'A:tionState> 
</iccl:Actlon> 
^cl:Actlon> 

<xcl:Label>dnjms</xcl: Label> 
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<xcl:Actb'nStatB> 

<drums selected=1rue"></drums> 

</xcl:ActionState> 
<xclActionState> 

5 <drums selected="false"></drums> 

</xcl:ActionState> 
</xcl:Action> 
<Accl:ActionSet> 
</kcl:Select> 

1 0 This select statement is the way to implement a complex 'droplisf . Each action has 

custom state definitions. 
ListBox 

<xcl:Select metaphor="iistbox'' selection="multi|slngle"> 
<xcl:Binding> 

15 <xcl:Query resources"http://vvww.infbcanvas.OQm/PFooess-oontainer/data.xmi"> 

//instrumentsPlayed 
</xcl:Query> 
</xcl:Binding> 
<xcl:ActionSet> 
20 <xcl:Actlon> 

<xcl:Label>ba$s</xcl:Label> 
^cl:ActionState> 

<bass selecteds=True'^</bass> 
</xcI:Act]onState> 
25 <xcl:ActlonStale> 

<bass selected="false"><ybass> 
</xcl:ActionState> 
<yycl:Action> 
<xcl:Action> 

30 <xcl:Labei>guitar</xGl:Labei> 

<xc!:ActionState> 

<guitar selected="true'*x/guitar> 
</xcl:ActionState> 
<xcl:ActionState> 

35 <guitar selected="false"></gu!tar> 

<^cl:ActionState> 
<A<cl:Actlon> 
<xcl:Action> 

<xcl:LabeI>drums</xcl:Label> 
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<xcl:ActionState> 

<drums seleGtod="true"x/drum$> 

</xc!:ActlonState> 
<xcl:ActionState> 

5 <clrums selected="false"></drums> 

</xcI:ActionState> 
</xcI:Actton> 
<Accl:ActionSet> 
<A(d:Select> 

10 This select statement is an example of a way to Implement a 'llstbox*. Each action has 

custom state definitions. 
ButtonGroup with HTML markup 
<xcl:Select metaphor="buttonGroup'' selection="sing]e"> 
<xcl:Binding> 

15 <xcl:QuefV resource="http7/Www.lnf6canva$.com/Process^ntainer/data.xmr> 

//instrumentPlayed 
</xcl:Query> 
</xcl:Binding> 
<xcl:ActionSet> 
20 <table> 

<tr> 

<td> 

<xcl:Action> 

^cl:ActlonState> 

25 <bass selecteds'*true'^</bass> 

</xcl:ActlonState> 
<xcl:ActionState> 

<bass selected="telse''></bass> 
</xcl:ActlonState> 
30 </xci:Action> . 

<Ad> 
<td> 

<xcl:Actlon metaphor="radloButton"> 
<xcl:ActionState> 

35 <guilars6lected="true"></guitar> 

</xcl:ActlonState> 
<xcl:ActionState> 

<gultar selected="false"> </guitaf> 
</xcl:ActionState> 
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</xcl:Aclion> 

<m> 

<td> 

<xcl: Action metaphor=-radloButton"> 
5 <xci.ActionState> 

<drums selected=true"> </dnjms> 
</xcl:AcUonState> 
<xcl:ActionState> 

<drums selected="false''> ^drums> 
10 </xcl:Ac«onState> 

</xclActlon> 

</td> 

<nr> 

</table> 

15 </xcl:ActionSet> 
<;/xcl:Select> 

This select statement is the way to Implement a 'radionbutton'. Each action has custom 

state definitions. 

MultiState Multiple Buttongroup 

20 <xcl:Select metaphor="buttonGroup" selection~"multi''> 
<xcI:Blndlng> 

<xcl:Queryresource=*htlp://vww.lnfocanvas.corn/Process-ccntainer/datajcnril"> 

//shoppingBasket 
</xcl:Query> 
25 </xcl:Bindlng> 
<xcl:ActlonSet> 

<xclActlon> 

<xcl:AGtionState> 
<xcl:Labe> 

30 <lmg src='../images/zilch.glf /> 

</xcl:Label> 
</xclActlonState> 
<xcl:ActionState> 
<xcl:Label> 

35 <jmg src='../images/basses1 .gif /> 

</xcl:Labei> 

<bass m1igr="fender"></bass> 
</xcl:ActionState> 
<xcl.ActlonState> 
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<xcl:Label> 

<Img srcs*. Jimages/basses2.gif /> 
</xcl:Label> 

<bass nrTfgr=1banez"></bass> 
5 </xcl:ActlonState> 

<xcl:ActionState> 
<xcl:Label> 

<img srcs'.7imagesA)asses3.gif /> 
<A(d:Labe> 

10 <bass mfgr»''stradK/arius''></bass> 

</xcl:ActionState> 
</xcl:Action> 
<xcl:Actlon> 

<xcl:ActionState> 
15 <xcl:Label> 

<img src='./images/zilch.glf /> 
</xd:Label> 
</xcl:AclionState> 
<xcl:ActionState> 
20 <xcl:Label> 

<lmg src=*.7images/guitars1.glf /> 
<^cl:Label> 

<guitar mfigrs''fiencler"></guitai> 
</xcl:ActionState> 
25 <xcl:ActionState> 

<xcl:Label> 

<img src='../images/gultars2.gif /> 
</xci:Label> 

<guitar mfgp="ibanez"></guitar> 
30 </xcl:ActionStatie> 

<xd:ActlonState> 
<xd:LabeI> 

<img src- ../images/guitars3.gif /> 
</xd:Label> 

35 <guitar mfgr="stradivarius"></gui1ar> 

</xcl*Act!onStatB> 
<Acd:Actlon> 
<xcl:Action> 

<!-notice: no action label-> 
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<xcl:ActionState> 

<xcl:ActionState> 
<xcl:Label> 

<img srcs'./rmages/znch.gif f> 
5 </xcl:Labe> 

</xcl:ActlonState> 
<xcl:Label> 

<img src='.7images/dnjmslgif /> 
</xcl:Label> 

10 <drums iTifgr="grelsch"></drums> 

</xcl:ActionState> 
<xcl.ActionState> 
<xcl:Label> 

<img src='.7images/drums2.gir /> 
15 </xcl:LabeI> 

<drums miigr="tafna"></dnjms> 
</xcl:ActionState> 
<xcl:ActionState> 
<xc!:Label> 

20 <img src- ../images/drums3.gir l> 

</xcl:Label> 

<drums m^ar="sears"></daims> 
</xcl.ActlonState> 
<A(Cl:Action> 
25 </xcl:ActionSet> 
</J(cl:Select> 

This select statement is an example implementation of a multi-state button. Note that It is 
much simpler than the functional equivalent logic if written In JavaScript. 
Edttorl 
30 <xcl:Edltor> 

<xcl:Bindlng> 

<xd:Queryresource="http:/Aiww.lnfocanvas.com/ProcGss-«)ntalner/^ 

//playsBass 
</xcl:Query> 
35 </xcl:Bindlng> 
</xcl:Ed]tor> 

This simple editor statement enables a multiple line editor lllce text area. 
Edttor2 

<xcl:Editor eventMap=''onBefbreUnload"> 
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<xcl:Binding> 

<xcI:Query resour(»='Tittp://wwwJnfocaiwas.com/Process-^ 

//playsBass 
</xcl:Query> 
5 </xcl:Binding> 
<A(d:EditDP» 

This simple editor statement enables a multiple line editor like text area that only updates 
right before the unload event. 



10 10. JAVASCRIPT API 

The JavaScript Process-container model is a set of ECMAscript objects provided to 
support the XCL Rule JavaScript programming model. The Engine supports edition 3 of 
ECMAScript, corresponding to JavaScript 1.5. The Script API starts with a set of global 
JavaScript functions: 
15 Current Component Scope 

XclComponent getCurrentComponent() 

This function accesses the current component scope. 
Current Document 
XclDocument getCun-entDocument() 
20 This function accesses the current document scope. 

Current Library 
XdLibrary getCurrentLibraryO 

This function accesses the cunrent library scope. 
Fetch Library 
25 XdLibrary getLibrary(URL library) 

This function accesses a library by VURL. 
Create Query 
XdQuery newQuery() 

This function creates a new XclQuery. 

30 

DOM Level (1 Bindings 

The JavaScript API supports Interaction with the presentation, logic, and data layers of 
the Process-container via a full W3 DOM level II JavaScript bindings. The following objects are 
defined as part of this DOIVI binding set: XclDOMString, XdDOIVTTimeStamp, 
35 XdDOMlmplementation. XdDocumentFragment, XdDocument, XclNode, XdNodeUst, 
XdNamedNodeMap. XdCharacterData. XclAttr, XclElement, XclText, XdComment, 
XdCDATASection, XclDocumenfType. XdNotation, XdEntity, XclEntityRefBrence, and 
XdProcessinglnstruction. 
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XclDOMString 

A DOMString is a sequence of 16-bit units. Applications must encode DOI^^String using 
UTF-1 6 (defined In [Unicode] and Amendment 1 of [ iSO/iEC 10646]). The UTF-16 encoding was 
chosen because of its widespread Industry practice. Note tiiat for botii HTIVIL and XML, the 
5 document character set (and therefore the notation of numeric character references) is based on 
UCS [ISO-10646). A single numeric character reference in a source document may therefore in 
some cases correspond to two 16-bit units in a DOMString (a high surrogate and a low 
surrogate). Even though the DOM defines the name of the string type to be DOMString, bindings 
may use different names. For example for Java, DOMString is bound to the String type because 
10 rt also uses UTF-1 6 as its encoding. As of August 1998, the OMG IDL specification included a 
wstring type. However, that definition did not meet the interoperability criteria of the DOM API 
since it relied on negotiation to dedde the width and encoding of a character. 

XclDOMTimeStamp 

15 A DOMTimeStamp represents a number of milliseconds. Even though the DOM uses 

the type DOMTimeStamp, bindings may use different types. For example for Java, 
DOMTimeStamp is bound to the long type. In ECMAScript, TImeStamp is bound to the Date type 
because the range of the integer type Is too small. 

20 XclDOMImplementation 

The XclDOMImplementation interface provides a number of methods for performing 

operations that are independent of any particular instance of the document object model. The 

DOMImplementatlon object has the following methods: 

boolean hasFeature() method 
25 boolean hasFeature(XcIDOMString feature, XclDOMString version) 

createDocumentTypeO method 
XclDocumentType create Docu mentType( 
XclDOMString quallfiedName, 
30 XclDOMString pubiicid, 
XclDOMString systemid 
) 

createDocument method() method 

35 XclDocument createDocument(namespaceURI, quallfiedName, doctype) 

XclDocumentFragment 

XcIDocumentFragment is a "lightweight" or "minimal" Document object It is very 
common to want to be able to extract a portion of a document's tree or to create a new firagment 
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of a document Imagine implementing a user command like cut or rearranging a document by 
moving fragments around. It is desirable to have an object wtiich can hold such fragments and it 
is quite natural to use a Node for this purpose. While it is true that a iDocument object could fulfill 
this role, a Document object can potentially be a heavyweiglit object, depending on the 
5 underlying implementation. What is really needed for this is a very lightweight object. 

XclDocumentFragment is such an object Furthemiore, various operations, such as inserting 
nodes as children of another Node, may take XclDocumentFragment objects as arguments; this 
results in ail the child nodes of the XclDocumentFragment being moved to the child list of this 
node. The children of a XclDocumentFragment node are zero or more nodes representing the 

1 0 tops of any sub-trees defining the structure of the document. XclDocumentFragment nodes do 
not need to be well-formed XMt documents (although they do need to follow the rules imposed 
upon well-formed XML parsed entities, which can have multiple top nodes). For example, a 
XclDocumentFragment might have only one child and that child node could be a Text node. Such 
a stmcture model represents neither an HTMt document nor a well-formed XML document. 

1 5 When a XclDocumentFragment is inserted into a Document (or indeed any other Node that may 
take children) the children of the XclDocumentFragment and not the XclDocumentFragment Itself 
are inserted into the Node. This makes the XclDocumentFragment very useful when the user 
wishes to create nodes that are siblings; the XclDocumentFragment acts as the parent of these 
nodes so that the user can use the standard methods from the Node interface, such as 

20 insertBefore and appendChild. XclDocumentFragment has the all the properties and methods of 
XclNode as well as the properties and methods defined below. 

XclDocument 

The XclDocument interface represents the entire HTML or XML document Conceptually, 
25 it is the root of the document tree, and provides the primary access to the document's data. 
Since elements, text nodes, comments, processing instructions, etc. cannot exist outside the 
context of a Document, the XclDocument interface also contains the factory methods needed to 
create these objects. The Node objects created have a ownerDocument attribute which 
associates them with the XclDocunrtent within whose context they were created. XclDocument 
30 has the all the properties and methods of Node as well as the properties and methods defined 
below. 



doctype property 
XclDocumentType doctype; 
35 The Document Type Declaration (see XclDocumentType) associated with this document 

For HTML documents as well as XML documents without a document type declaration this 
returns nuH. The DOM Level 2 does not support editing the Document Type Declaration, 
therefore docType cannot be altered In any way. including through the use of methods, such as 
InsertNode or removeNode, which are Inherited firom the Node interface. 
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implementation property 

XclDomlmplementation implementation; 

The XclDOMImpIementation object that handles this document. A DOM application may use 
5 objects from multiple implementations. 

documentElement property 
XcIEIement documentEJement; 

This is a convenience attribute that allows direct access to the child node that is the root 
10 element of the document. For HTML documents, this is the element with the tagName "HTML". 

createElementQ method 

XcIEIement createElement(XcIDOMString tagName) 

15 createDocumentFragmentO method 

XclDocumentFragment createDocumentFragmentO 

createTextNode{) method 

XclText aeateTextNode(XciDOMString data) 

20 

createComment(data) method 

XclComment createCommentpcdDOMString data) method 

createCDATASection(data) method 
25 XclCDATASectlon createCDATASection(XcIDOMString data) method 

createProcessinglnstructionO method 
XclProcessinglnstructioncreateProcessingtnstruction( 
XclDOMStrIng target. 
3D XciDOMString data 
) 

createAttributeO method 
XclAttr createAttribute(XclDOMStr(ng name) 
35 Creates an Attr of the given name. Note that the Attr instance can then be set on an 

Element using the setAttrlbuteNode method. To CTeate an attribute with a qualified name and 
namespace URI, use the createAttributeNS method. This method returns a new Attr object with 
the nodeName attribute set to name, and localName. prefix, and namespaceURI set to null. 
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createEntityReferenceO method 

XclEntityReference createEntityReferenoe(XclDOMString name) 

getElementsByTagNameO method 
5 XclNodeList getElementsByTagName(XclDOMString tagname) 

importNodeQ method 

XdNode importNode(XciNode importedNode, boolean deep) 

10 createEIementNSO method 

XclElement crealeElementNS( 
XclDOMString namespaceURI, 
XdDOMString qualified Name 
) 

15 

createAtfributeNSQ method 

XclAttr createAttrlbuteNS( 
XclDOMString namespaceURI, 
XclDOMString qualifiedName 
20 ) 

getElementsByTagNameNSQ method 
XclNodeList getElementsByTagNameNS( 
XclDOMString namespaceURI, 
25 XclDOMString localName 
) 

getElementByldO method 

XclElement getElementByld(XclDOMString elementid) 

30 

parseXMLStringO method 

XclNode parseXMLStrlng(String xml) 

This is a Process-container specific extension to DOM level 2. 

35 XclNode 

The XclNode Interface is the primary datatype for the entire Xcl Document Object Model. 
It represents a single node in the document tree. While all objects Implementing the XclNode 
interface expose methods for dealing with children, not all objects Implementing the XclNode 
interface may have children. For example, XclText nodes may not have children, and adding 
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children to such nodes results in a I^OMException being raised. The attributes nodeName. 
nodeValue and attributes are included as a mechanism to get at node information without casting 
down to the specific derived interface. In cases where there is no obvious mapping of these 
attributes for a specific nodeType (e.g., nodeValue for an XclElement or attributes for a 
5 XclComment), this returns null. Note that the specialized interfaces may contain additional and 
more convenient mechanisms to get and set the relevant information. 

Constants 

The XctNode dass has the following constants: 
10 •XclNode.ELEMENT^NODE: This constant is of type short and its value Is 1 . 

•XclNode.ATTRIBUTE_NODE: This constant is of type short and its value Is 2. 

•XclNode.TEXT_NODE: This constant Is of type short and its value is 3. 

•XciNode.CDATA_SECTION_NODE: This constant is of type short and its value is 4. 

•XclNode.ENTiTY_REFERENCE_NODE: This constant Is of type short and its value is 5. 
1 5 •XclNode.ENTITY.NODE: This constant is of type short and Its value is 6. 

*XclNode.PROCESSINGJNSTRUCTION_NODE: This constant is of type short and its value is 

7. 

•XclNode.COMMENT.NODE: This constant is of type short and its value is 8. 

*XclNode.DOCUMENT_NODE: This constant is of type short and its value is 9. 
20 •XclNode.DOCUMENT_TYPE_NODE: This constant is of type short and its value is 10. 

•Xc1Node.DOCUMENT_FRAGMENT_NODE: This constant is of type short and its value is 11. 

•XclNode.NOTATION_NODE: This constant.is of type short and Its value Is 12. 

nodeName property 

String nodeName 
25 nodeValue property 

String nodeValue 

nodeType property 

short nodeType 

parentNode property 
30 XclNode parentNode 

chlldNodes property 

XclNodeLlstchildNodes 

firstChild property 

XcINodefirstChild 
35 lastChild property 

XclNode iastChild 

prevlousSibling property 

XclNode prevlousSibling 

nextSiblIng property 
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XclNode nextSibling 
attributes property 
XclNamedNodeMap attributes 
ownerOocument property 
5 XdDocument ownerOocument 
namespaceURI property 
String namespaceURI 
prefix property 
String prefix 
10 locatName property 
String localName 
insertBeforeQ method 

XclNode fnsertBeft>re(XclNode newChild, XclNode refChild) 

replaceChildO method 
1 5 XclNode replaceChild(XclNode newChlld. XclNode oldChikJ) 

removeChildO method 

XclNode removeChild(XciNode oldChild) 

appendChildO method 

XclNode appendChild(XclNode newChild) 
20 hasChildNodesO method 

boolean hasChildNodesO 

cloneNode(deep) method 

XclNode cloneNode(boolean deep) 

normalizeO method 
25 void normalizeO 

supports(feature, version) 

boolean supports(Xct£)OMString feature. XclDOMStrfng versfon) 
XclNodeLlst 

30 The NodeList Interface provides the abstraction of an ordered collection of nodes, 

without defining or constraining how this collection is implemented. NodeList objects in the DOM 
are live. The items in the NodeList are accessible via an integral index, starting from 0. 

length property 
35 int length 

item() method 

XclNode ltem(unsigned long Index) 
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The index parameter is of type unsigned long. Ttiis object can also be differentiated 
using square braclcet notation (e.g. obj[1]). Differentiating with an integer index Is equivalent to 
invoicing the item' method with that Index. 



5 XciNamedNodeiMap 

Objects Implementing the NamedNodeMap interface are used to represent collections of 

nodes that can be accessed by name. Note that NamedNodelMap does not inherit from NodeList; 

NamedNodeMaps are not maintained in any particular order. Objects contained in an object 

implementing NamedNodelVlap may also be accessed by an ordinal index, but this Is simply to 
1 0 allow convenient enumeration of the contents of a NamedNodeMap, and does not imply that the 

DOf\^ specifies an order to these Nodes. NamedNodeMap objects in the DOM are live. 



length property 

int length 
15 getNamedKemO method 

XclNode getNamedltem(XciDOMString name) 

setNamedHemQ method 

XclNode setNamedltem(XclNodearg) 

removeNamedltemO method 
20 XclNode removeNamedltem(XciDOMString name) 

itemQ method 

XclNode item(unsigned long Index) 

This object can also be diflerentiated using square braclcet notation (e.g. obj[1]). 

Differentiating with an integer Index is equivalent to involdng the Item method with that index. 
25 getNamedltemNSO method 

XclNode getNamedltemNS(XclDOMString namespaceURI, XclDOMString iocalName) 

setNamedltemNSO method 

XclNode setNamedltemNS(XclNode arg) 

removeNamedltemNSO method 
30 XclNode removeNamedltemNS( 

XclDOMString namespaceURI. 

XclDOMString IocalName 

) 

XclCharacterData 

35 The CharacterData interface extends Node with a set of attributes and methods for 

accessing character data in the DOM. For clarity this set is defined here rather than on each 
object that uses these attributes and methods. No DOM objects correspond directly to 
CharacterData, though Text and others do Inherit the interface from it All offsets in this interface 
start from 0. As explained in the DOMString interface, text strings in the DOM are represented in 
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UTF-16, /.e. as a sequence of 16>bit units. In the following, the temi 16-bit units is used 
whenever necessary to indicate that indexing on CharacterData is done in 16-bit units. 
CharacterData has the all the properties and methods of IMode as well as the properties and 
methods defined below. 

5 

data property 
String data 
length property 

int length 
10 substring Data() method 

XclPOMString substrjngData(unslgned long ofHset, unsigned long count) 

appendDataO method 

void appendData(Xc(DOMString arg) 

InsertDataO method 
1 5 void in$ertData(unslgned long oflset, unsigned long arg) 

deleteDataO method 

void deleteData(unsigned long offset, unsigned long count) 
replaceDataO method 
void repiaceData( 
20 unsigned long ofliset, 
unsigned long count, 
unsigned long arg 
) 

XclAttr 

25 The Atlr interface represents an attribute in an Element object Typically the allowable 

values for the attribute are defined in a document type definition. 

Attr objects Inherit the Node interface, but since they are not actually child nodes of the element 
they describe, the DOM does not consider them part of the document tree. Thus, the Node 
attributes parentNode. previousSibling, and nextSibling have a null value for Attr objects. The 

30 DOM tai(es the view that attributes are properties of elements rather than having a separate 
Identity from the elements they are associated with; this should makB it more efficient to 
Implement such features as default attributes associated with all elements of a given type. 
Furthermore, Attr nodes may not be immediate children of a XclDocumentFragment. However, 
they can be associated with Element nodes contained within a XclDocumentFragment. In short. 

35 users and impiementers of the DOM need to be aware that Attr nodes have some things in 
common with other objects inheriting the Node interface, but they also are quite distinct. 
The attribute's effective value is determined as follows: if this attribute has been explicitly 
assigned any value, that value is the attribute's effective value; othenwise, if ttiere is a declaration 
for this attribute, and that declaration includes a default value, tt>en that default value is the 
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attribute's effective value; otherwise, the attribute does not exist on this element In the structure 
model until it has been explicitly added. Note that the nodeValue attribute on the Attr Instance 
can also be used to retrieve the string version of the attribute's value{s). 

In XML, where the value of an attribute can contain entity references, the child nodes of 
5 the Attr node provide a representation in which entity references are not expanded. These child 
nodes may be either Text or EntityRefsrence nodes. Because the attribute type may be 
unknown, there are no tokenized attribute values. Attr has the all the properties and methods of 
Node as well as the properties and methods defined below. 

10 name property 

String name 

specjfied property 

boolean specified 

value property 
15 String vaiue 

ownerElement property 

XclElement ownerElement 

XclElement 

20 The XclElement interface represents an element in an HTML or XIVIL document. 

Elements may have attributes associated with them; since the XclElement Interface inherits from 
XclNode, the generic XclNode interface attribute attributes may be used to retrieve the set of all 
attributes for an element There are methods on the XclElement Interface to retrieve either an 
XclAttr object by name or an attribute value by name. In XML, where an attribute value may 

25 contain entity references, an XclAttr object should be retrieved to examine the possibly feirty 
complex sub-tree representing the attribute value. On the other hand, in HTML, where all 
attributes have simple string values, methods to directly access an attribute value can safely be 
used as a convenience. In DOM Level 2, the method nonnalize is Inherited fifom the Node 
Interface where It was moved. Element has the all the properties and methods of Node as well 

30 as the properties and methods defined below. 

tagName property 
String tagName 
getAttrlbute() method 
35 XclDOMString getAttribute(XclDOMString name) 
setAttrlbuteO method 

void setAttribute(XclDOMString name, XclDOMString value) 

removeAttributeO method 

void removeAttribute(XclDOMString name) 
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getAttributeNodeO method 

XclAttrgetAttributeNode(XclDOMSlrlng name) 
setAttributeNodeO method 
XdAttr setAttrlbuleNode(XclAttr newAttr) 
5 removeAttributeNodeO method 

XclAttr removeAttrfbuteNode(XciAttr oldAttr) 
getElementsByTagName() method 
XciNodeList getElementsByTagName(XctDOMString name) 
getAttrlbuteNSQ method 
1 0 XclDOMString getAttributeNS{ 
XclDOMString namespaceURI, 
XclDOMString (ocalName 
) 

setAttributeNSO method 
15 voldsetAttributeNS( 

XclDOMString namespaceURI, 
XclDOMString qualifiedName, 
XclDOMString value 
) 

20 removeAttributeNSQ method 
void removeAttributeNS< 
XclDOMString namespaceURI, 
XclDOMString localName 

) 

25 getAttributeNodeNSO method 
XdAttr getAttributeNodeNS( 
XdDOMString namespaceURI, 
XdDOMString localName 
) 

30 setAttributeNodeNSO method 

XclAttr setAttrrbuteNodeNS(XclAttr newAttr) 
getElementsByTagNameNSO method 
XdNodeLlstgetElementsByTagNameNS( 
XdDOMString namespaceURI, 
35 XdDOMString localName 
) 

haeAttrlbirteO method 

boolean hasAttribute(XclDOMStrir^ name) 
hasAttributeNSO method 
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boolean hasAttributeNS( 
XclDOMStiing namespaceURI, 
XclOOMString localName 

) 

5 XclText 

The XclText Interface inherits from XclCharacterData and represents the textual 
content (temned character data in XML) of an XclElement or XclAttr. If there is no markup Inside 
an element's content, the text is contained in a single object Implementing the XclText Interface 
that is the only child of the element. If there is markup, it is parsed into the Information items 

1 0 (elements, comments, etc.) and XcTText nodes that form the list of chDdren of the element When 
a document Is first made available via the DOM, there is only one XclText node for each block of 
text Users may create adjacent XclText nodes that represent the contents of a given element 
without any Intervening markup, but should be aware that there is no way to represent the 
separations between these nodes in XML or HTML, so they will not (in general) persist between 

15 DOM editing sessions. The normaiize() method on XclNode merges any such adjacent XdText 
objects into a single node for each block of text. XclText has the ail the properties and methods 
of XclCharacterData as well as the properties and methods defined below. 

splitTextO method 
20 XclText splitText(unsigned long offiset) 
XclComment 

XciComment has the all the properties and methods of XclCharacterData as well as the 
properties and methods defined below. 
XclCDATASectfon 

25 CDATA sections are used to escape blocks of text containing characters that would 

othenwlse be regarded as markup. The only delimiter that is recognized in a CDATA section is 
the "]]>" string that ends the CDATA section. CDATA sections cannot be nested. Their primary 
purpose is for including material such as XML fragments, without needing to escape all the 
delimiters. The XclDOMStrlng attribute of the Text node holds the text that is contained by the 

30 CDATA section. Note that this may contain characters that need to be escaped outside of 
CDATA sections and that, depending on the character encoding ("charset") chosen for 
serialization, it may be impossible to write out some characters as part of a CDATA section. The 
XclCDATASection Interface Inherits from the XclCharacterData interface through the XclText 
interface. Adjacent XclCDATASections nodes are not merged by use of the normalize method of 

35 the XclNode interface. Because no markup is recognized within a CDATASection, character 
numeric references cannot be used as an escape mechanism when serializing. Therefore, action 
needs to be taken when serializing a XclCDATASectton with a character encoding where some 
of the contained characters cannot be represented. Failure to do so would not produce well- 
formed XML. One potential solution in the serializatton process is to end the CDATA section 
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before the character, output the character using a character reference or entity reference, and 
open a new CDATA section for any further characters in the text node. Note, however, that some 
code conversion libraries at the time of writing do not return an error or exception when a 
character Is missing from the encoding, maldng the task of ensuring that data is not corrupted on 
5 serialization more difficult. CDATASection has the all the properties and methods of Text as well 
as the properties and methods defined below. 

XclDocumentType 

Each XclDocument has a doctype attribute whose value is either null or a XclDoc- 
10 umentType object. The XclDocumentType interface in the DOM Core provides an interface to the 
list of entities that are defined for the document, and little else because the effect of namespaces 
and the various XML schema efforts on DTD representation are not currently standardized. The 
DOM Level 2 does not support editing XclDocumentType nodes. XclDocumentType has the 
all the properties and methods of XclNode as well as the properties and methods 
15 defined below. 

name property 

String name 

entities property 
20 XclNamedNodeMap entities 

notations property 

XclNamedNodeMap notations 

pubiicid property 

String publrcid 
25 systemld property 

String systemld 

IntemalSubset property 

String internalSubset 

XclNotation 

30 This interface represents a notation declared in the DTD. A notation either declares, by 

name, the format of an unparsed entity (see section 4.7 of the XML 1 .0 specification), or is used 
for formal declaration of processing instruction targets (see section 2.6 of the XML 1,0 
specification). The nodeName attribute Inherited from XclNode Is set to the declared name of the 
notation. The DOM Level 1 does not support editing XclNotation nodes; they are therefore read 

35 only. A XclNotation node does not have any parent XclNotation has the all the properties and 
methods of XclNode as well as the properties and methods defined below. 

pubiicid property 
String pubiicid 
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systemid property 
String systemid 

XclEntRy 

5 This Interface represents an entity, either parsed or unparsed, in an XML document 

Note that this models the entity itself not the entity declaration. Entity declaration modeling has 
been left for a later Level of the DOM specification. The nodeName attribute that is inherited 
from XclNode contains the name of the entity. An XML processor may choose to completely 
expand entitles before the structure model is passed to the DOM; in this case there will be no 

1 0 XdEntityReference nodes in the document tree. XML does not mandate that a non-vaildatlng 
XML processor read and process entity declarations made in the external subset or declared in 
external parameter entities. This means that parsed entities declared in the external subset need 
not be expanded by some classes of applications, and that the replacement value of the entity 
may not be available. When the replacement value is available the conresponding XclEntlty 

1 5 node's child list represents the structure of that replacement text. Othenvise, the child list is 
empty. The DOM Level 2 does not support editing XclEntlty nodes; if a user wants to make 
changes to the contents of an XclEntlty, every related XdEntityReference node has to be 
replaced in the stmdure model by a done of the XclEntit/s contents, and then the desired 
changes must be made to each of those clones instead. XdEntity nodes and all their 

20 descendants are read only. 

An XclEntlty node does not have any parent. If the entity contains an unbound 
namespace prefix, the namespacellRI of the corresponding node in the XdEntity node subtree is 
null. The same is true for XdEntityReference nodes that refer to this entity, when they are 
created using the createEntityReference method of the XdDocument interface. The DOM Level 2 

25 does not support any mechanism to resolve namespace prefixes. XdEntity has the all the 
properties and methods of XclNode as well as the properties and methods defined below. 

publicld property 
String publicld 
30 systemid property 
String systemid 
notationName property 
String notationName 
XdEntityReference 

35 XdEntityReference objects may be Inserted into the structure model when an entity 

reference is In the source document, or when the user wishes to insert an entity reference. fSlote 
that character references and references to predefined entitles are considered to be expanded 
by the HTML or XML processor so that characters are represented by their Unicode equivalent 
rather than by an entity reference. Moreover, the XML processor may completely expand 
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references to entities while building the structure model, instead of providing XclEntityReference 
objects. If it does provide such objects, then for a given XclEntityReference node, it may be that 
there is no XciEntity node representing the referenced entity, if such an XdEntity exists, then the 
subtree of the XclEntityReference node is in general a copy of the XciEntity node subtree. How- 
5 ever, this may not be true when an entity contains an unbound namespace prefix. In such a 
case, because the namespace prefix resolution depends on where the entity reference is, the 
descendants of the XclEntityReference node may be bound to different namespace URIs. As for 
XciEntity nodes, XclEntityReference nodes and all their descendants are read only. 
EntityReference has the all the properties and methods of XclNode as well as the properties and 
1 0 methods defined below. 

XclProcesslnginstruction 

The XclProcesslnginstruction Interface represents a "processing Instoictlon", used in 
XML as a way to keep processor-specific information in the text of the document. 
15 Processing instruction has the all the properties and methods of XclNode as well as the 
properties and methods defined below. 

data property 

String data 
20 XclComponent 

This is the javascript binding for an XCL Component It Inherits ali the properties 

and methods of XclElement. 

executeO method 

XclNodeListexecute() 
25 executes this component 

getNameO method 

String getName() 

Retums the name of the rule, as a String. 

setNameQ method 
30 void setName() 

Sets the name of the rule to the specified string. 

getParameter{) method 

XclParametergetParameter(String name) 

getPublishO method 
35 XclPublish getPubilsh(Strlng name) 

getSubscribeQ method 

XclSubscribe getSubscribe() 

getVarlableO method 

XclVariable getVariable(String name) 
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setParameterO meffhod 

void setParameter(XcINodeList pafameter) 

XclLibrary 

This is the javascript binding for an XCL Library. It Inherits ail tiie properties and 
5 metiiodsofXclDocument. 

getComponent() method 

XclComponent getComponent(String name) 

getQueryO method 

XclQuery getQuery(String name) 
10 gelRuleO method 

XclRule getRule(String name) 

getSwatchO method 

XclSwatch getSwatch(Strlng name) 

getTransform 
15 XcrTransfonm getTransfbnm(String name) 

XclQuery 

This JavaScript API supports the interaction with XCL Query. XclQuery has the all the 

properties and methods of XclComponent as well as the properties and methods defined below. 

deleteNodeO method 
20 public boolean deleteNode(int position) 

getCurrentPosO method 

public int getCurrentPos() 

getResuKO method 

XclNode getResult(jnt position) 
25 getResultCountO method 
- int getResultCountO 

getResultsO method 

XclNodeLlstgetResultsO 

InsertNodeO method 
30 boolean insertNode(XclNode node) 

moveFtrstChunkO method 

void moveFlrstChunkO 

moveNextChunkO method 

void moveNextChunkO 
35 movePreviousChunkO method 

void movePreviousChunkO 

moveUastChunkO method 

void moveLastChunkO 

moveFlrstltem() method 
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boolean moveFirstllem() 

moveLastltemO method 

boolean moveLastltem() ^ 

moveNextltemO method 
5 boolean moveNextltemO 

movePreviousltemO method 

boolean movePreviousltem() 

setQueryContextO method 

void setQueryContext(String contextName) 
10 setQueryResourceO method 

void setQueryResource(String resourceName) 

setQueryStringO method 

void setQueryString(String expression) 

Sets this quer/s xpath expression. 
15 XclRule 

This is the JavaScript binding for an XCL Rule. It inherits all the properties and 
methods of XclComponent 
XclSwatch 

This is the JavaScript binding for an XCL Swatch, it inherits all tiie properties and 
20 methods of XdComponent. 
XclTransform 

This is the JavaScript binding Ibr an XCL Transform. K inherits ail the properties and 
methods of XclComponent. 
XclVariable 

25 This is the JavaScript binding for an XCL Variable. It inherits all the properties and 

methods of XclElement. 

getValue() method 

public XclNodeList getValue() 

setValueO method 
30 public void setValue(XclNodeLlst value) 

getNameQ method 

String getName() 

setNameQ method 

String setName() 
35 XclParameter 

This is the JavaScript binding for a Component Parameter. It Inherits all the properties 
and methods of XCL Variable. 
XclPubfish 
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This is the JavaScript binding for a Pubfish Variable, it inherits ail the properties and 
methods of XCL Variable. 
getArticleO method 
String getArticleO 
5 setArticieO method 

void setArticle(String name) 
getPassthroughO method 
boolean getPassthrough() 
setPassthroughO method 
10 boolean setPassthrough(String name) 
fireO method 
void fire{) 

getTriggerO method 
String getTrigger() 
15 setTrlgger() method 

void setTrigger(Strlng trigger) 
XdSubscribe 

This Is the JavaScript binding for a Subscribe Variable, it inherits all the properties 
and methods of XCL Variable. 
20 getTriggerO method 
public String getTriggerO 
setTriggerO method 
public void setTrigger(String trigger) 
XclEvent 

25 The JavaScript API supports the manipulation of XCL Events. 

XclWidget 

The JavaScript API supports the manipulation of Instances of XCL WidgeL 
XciCollection 

The JavaScript API supports the manipulation of instances of XCL Collection. 
30 XcUournal 

The JavaScript API supports the manipulation of the Process-container Journal. 

Names 

The JavaScript API supports the Interaction with Java JNDI. 
Services 

35 The JavaScript API supports the interaction with any Process-container Service 

Internee. 
HTML IModel 

The JavaScript API supports the manipulation of HTML within the Page using W3 DOIVI 
Level 2 HTML bindbgs. 
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XSLT Model 

The JavaSaipt API supports the manipulation of XSLT within the Page using a set of 
proprietary XSLT bindings. 
CSS IVlodel 

5 The JavaScript API supports the manipulation of CSS within the Page HTIVIL using a set 

of proprietary CSS bindings. 

11. EXTENSION API 

The Process-container Extensions technology is the way that the Process-container 
10 Engine supports extensions of its capabilities through 'plug-in' Java implemented functionality. 
These plugins are based on the Java Servlet interface with special added Process-container 
Extension semantics. 

Permission Installed 

1 5 One very important characteristic of an Extension is that unitize Process-containers which 

can arrive in your engine in a highly dynamic manner, Extensions are explicitiy downloaded and 
installed. This means that Extensions can be more powerful than Process-containers without 
causing any undue security concerns, in fact unlike Process-containers, standard Java security 
models are supported that allow an extension to access operating system level network and lite 

20 i/o, window functionality, etc. 

J2EE Conformant 

The Extensions environment is expected to have a appropriate level of J2EE 

conformance guaranteed. This is used to allow Extensions to be designed to run on J2EE 
25 compatible platforms and allow the user to use the full J2EE environment if desired with such 
things as transactional guarantees expressed consistently across the JDBC, EJB, and JMS 
worlds. 

Extension Scenarios 

30 This Is to support the following example extension scenarios: Transport Extension, 

Protocol Extension, Replication Protocol, Tracking Protocol, Database integration, Application 
integration, Self contained Application, and Analytic Extenstons. 

Extension Architecture 

35 Turning to FIG. 45. the extensions architecture is much like Process-container 

Execution, but instead of Process-containers being executed, Extenstons are being executed. 
They interact with the ProcessK»ntalner Engine via the Extension API The Extension API 
includes the following elements: Extension Objects, Support Layer packages, and Runtime 
Layer Objects. 
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Extension as Servlet 

All Extensions may be Java HTTP Servlets. This means that they support the Servlel 
Interface. This provides: HTTP request/response processing and Bfecycle <startup/shutdown) 
5 services. 

Extension Llfecycle 

Extensions use the Java Servlet interface lifetime services. This means that Extensions 
are started up when the assodated servlet Is first brought into scope, and shut-down when the 
1 0 associated servlet leaves scope. Entering scope can happen when the extension is statically 
Installed and the engine is booted, and after the extension is dynamically installed (downloaded) 
and configured. 

Dynamic Extensions 

1 5 Extensions can be downloaded from the network using standard URLs. When they are 

down-loaded, they are started up. The first Hme they are loaded, persistent properties can be set 
that are used to configure the extension using the Java JNDI interface. This dynamic 
configuration allows the downloaded Extension to guarantee it is configured properly before it Is 
used. 

20 

Extension as Service 

All Extensions can also be an instance of Process-container Sendee Intertiace. This 
allows Extensions to provide services to other Extensions as well as executing Process- 
containers through the JavaScript API. 

25 

Extension API 

The Extensions API provides access to the following Process-container Engine 
functionality: the ability to create a Process-container with a specified VURL; the ability to delete 
a Process-container with a specified VURL; and the ability to clone a Process-container with a 
30 specified VURL to create a duplicate Process-container with a different specified VURL 

Extension Objects 

The following are the basic Extension objects: 

35 Process-contalnerExtenslon 

The Process-containerExtension is a subtype of HTTPServlet flnom the Java Servlet 
package. This is the class that Is subtyped In order to create an implementation of a desired 
Extension. 
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Process-containerEngine 

The Process-conlainerEngine is available from thie Process-oontainerExtenslon, and 
represents a very high level Extension API specific abstraction of functionality of the Process- 
container Engine capabilities. These include the Process-container Factory, Process-container 
5 Persistence, and Engine Lifecycie. 

Process-container 

The Process-container object is an Extension API specific abstraction of the Process- 
container object in-the Process-container Layer, it represents the following capabilities: Prooess- 
10 container Shell Annotation Management, Process-container Transaction Management, Process- 
container Attachment Management, Process-container Journal Management, and Process- 
container State. 

Process-containerTransaction 
15 The Process-container Transaction object is an Extension API specific abstraction of the 

Process-container Transaction. 

Process-containerJoumal 

The Process-containerLog object is an Extension API specific abstraction of the 
20 Process-container Journal. 

Support Layer packages 

There are certain Support Layer pad^ages that are visible from, and expected to be used 
with the Extensions API: Java JNDI. Java JMS, Java Sen^let, Xerces DOM/XML. and Xalan 
25 XSLT/XPATH. It is important to realize that Extensions can use, and are encouraged to use 
these paclcages. For instance these are guaranteed to be available in both Process-container 
Client and Process-container Server peer configurations. 

Runtime Layer Objects 

30 There are certain Runtine Layer objects that are visible from, and expected to be used 

with the Extensions API: Process-container Session Subsystem. Process-container Event 
interface, Process-container Attachment Interface, Process-container Packet Interface. Process- 
container Email Interface, Process-container Message Interface, and Process-container Sen/ice 
Interface. < 

35 

Self contained Application 

It is assumed that Extensions will be written that represent self-contained appltoations. 
These applications rely on the manipulation of Process-containers and other Extension API 
capabilities, to create a part of or a whole of an application. 
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Analytic Extensions 

It is assumed that Extensions will be written that represent rules engines or other analytic 
capabilities. These are generic semantic drivers, but do not represent connectivity or integration 
5 with external standards or subsystems. 

12, PROCESS-CONTAINER STORE 

The Process^ntalner Store Is a subcomponent of the Runtime Layer that provides a 

10 fundamental capability to make Process-container instances and associated XML core objects 
persistent The Process-container Store attempts to malce as few decisions about how a 
Process-container is stored as possible. Types of Storage include Standalone document 
storage, Database Blob storage, and/or Database Sbuctured storage. The defauH scheme is to 
manage ProcessKX)ntainer8 as standalone documents In flat file systems. An alternate scheme 

15 is to manage Process-containers as blobs in database systems. Another altemate scheme is to 
manage Process-containers as structured data in XI^L aware database systems. 

Transactionality 

The Process-container Store is transactionally manipulated using Java JTA transactions. 

20 This means the following things: Atomic: Any changes to a Process-container made within a 
JTA-transaction either are ail made or none are made; isolation: Process-containers may not 
necessarily be transactionally isolated from multiple run-time users. This Isolation may be done 
via conventions between users; Durable: Any changes to a Process-container made within a 
JTA-transaction once made, are available 

25 even if the system has crashed. 

Persistent Objects 

The Store uses three types of storage to capture the shared and non-shared state of a 
Process-container Serialized Process-container, Serialized Journal, and/or Serialized Binders. 

30 The Serialized Process-container is an XML document that Is the serialized form of the Process- 
container XML minus the instances of Process-container Resource it has Imported through 
Binders. The Serialized Journal is an XML document that is the serialized form of the Process- 
container XML minus the instances of Process-container Resource it has imported through 
Binders. Serialized Binders are stored separately from the Process-container and Journal 

35 because they are potentially shared resources across multiple Process-container instances. 

The Store supports a set of types of Indexing fior Process-containers contained within it 
Process^ntainers are automatically accessible by specifying their identity using the Process- 
container's Resource VURL Resource. Process-containers are also accessible by Process^ 
container Variable. These are instances of XCL Variable placed within the body of the Process- 
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container itself. Otiier features include ProcessK^ntainer Management; Binder Management; 
Downloading: Caching; Authentication, and Versioning. 

13, DISTRIBUTION 

5 The Process-container environment has a unique set of distribution challenges and 

opportunities because of the asynchronous nature of Process-containers. 

Process-container Mobility 

Process-containers are first of all asynchronous self contained portable agents. This 
10 means that they can be moved around easily between Instance of a Process-container Peer. The 
Process-container Engine by itself however knows nothing about the mechanics of transport. 
This is contained in the one or more instances of a Transport Extension. The Transport may or 
may not implement the desired protocols corhpletely so the Extensions API supports the creation 
of instances of Protocol Extension to enhance protocols beyond what the Transport provides. 

15 

Messaging 

The Process-container Engine may rely on the availability of a Java JMS provider. The 
l^untime Layer and the Extension API are designed to allow the use of standard messaging 
systems to move Process-containers, Email, and other infomiation between Engines. A 
20 Process-container Distribution Protocol may be used as well as a Pipelined Messaging 
Architecture. 

Transport Extension 

Transports are special types of Process-container Extensions that provide connectivity 
25 via various transports. Asynchronous transports are supported by the Process-container 
Environment. Examples of asynchronous transports are: 

EMAIL: a ubiquitous store and forward transport characterized by unreliable delivery. 
Send protocols are usually different from receive protocols. Send protocol is usually 
SMTP or MAPI. Receive protocols are typically POP. IMAP. or MAPI. 
30 QUEUE: Queuing Is a store and fonvard transport characterized by reliable, often 

transactional delivery. There are commonly publish/subscribe interest based filtering 
mechanisms associated with this type of transport. Examples are Microsoft MSMQ, IBM 
MQSeries, and TiBCO. Almost all of these can be access via the JAVA JMS interface. 

Synchronous transports are supported by the Process-container environment as well. 
35 Examples are: 

HTTP: A ubiquitous request-response protocol, this MIME based delivery mechanisms 
was designed to support browser interactions, but has matured to support more standard 
transport scenarios. 
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HOP: Used by both CORBA and Java RMI remote procedure calls, this transport is 
typicaify used for highly structured procedural calls. 

FTP: Used throughout the WEB world, this an efficient thotjgh unreliable synchronous 
protocol for exchanging Process-containers and related objects as byte-streams. 

5 

Protocol Extension 

The Extensions API may be used to support Process-container Protocols that are not 
standard parts of the Process-container Environment Below are some examples: 

10 Reliable Delivery Protocol 

The Process-container Environment supports a special type of extension protocol called 
the Process-container Distribution Protocol SDP. This protocol is transport independent and adds 
special features to both asynchronous and synchronous transports. The SDP provides the 
capability to ensure that between two engine endpoints, a given message of a given Identity is 

1 5 received at least once. If there is some failure at the transport layer which causes a given 

message to be lost then the message will be resent until successful delivery is aciuiowiedged. If 
duplicate messages are sent, then the duplicates will be culled from the receiving side. The SDP 
provides the capability to have the sending side receive out of band notifications of various SDP 
events. Examples are: successful delivery and unsuccessful delivery. 

20 

Synchronization Protocol 

A Synchronization protocol Is where a Process-container that was transported to another 
Process-container Engine can have the remote version send its updates back to the original 
clone. 

25 

Replication Protocol 

A Replication protocol is where a Process-container that was transported to another 
Process-container Engine can have updates to the original replicated to the remote Process- 
container. 

30 

Load Balancing Protocol 

A Partitioning prototocol is where incoming messages can be re-dlrected to another 
Process-container Engine in order to balance workload across multiple Process-container 
Engines. 

35 

Tracking Protocol 

A Workflow prototocol Is where events on remote Process^contalners can be received by 
extensions within the local Process-container Engine. 
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14. OTHER FEATURES 
Integration 

5 The Process-container environment is designed to support integration with external 

products. Features Include Database integration including Mapping Process-container 
Transactions XML to and from external data sources and Asynchronous Synchronization 
Protocols, and Application Integration Including SQL integration and API Integration. 

1 0 Other features Include Profiling and Authoring . To support authoring features including 

a Proces&«ontalnerTool, XCL Wizards, XCL Libraries, XCL Binders. XCL runtime debugging 
are provided. 

Indexing 

15 Indexing support is provided in the Process-container environment in order to create 

Index' transactions that can be used locate and access resources. The Usage Model provides 
that indices are used to support the access, through queries, of organized abstractions of d^ta 
called 

indexes. Examples of index usage include: Dynamic Table of Contents, Help indexes, 
20 Application specific directories, Glossaries, Cross references/Hyper Uniting. 

Navigation 

Indices are designed to support publish-subscribe events that are directed to the page. 
Inter-Process-container indexing is also possible. 

25 

Processing Model 

As illustrated in FIG. 46, the overall architecture of the Index model is divided into three 
conceptual constructs: Indexing sources, index processing, and a resultant set of indexing 
transactions. Indices are built based on information that is extracted from: XCL components, 
30 Javascript API, and Extensions API. The Rurvtlme model includes read and write accesses. 
Indices are used at run-time in the following ways: read and write access throii^h the Javascript 
API; read and write access through the Extension API; and read and write access through XCL 
components. 

35 Discretion 

Discretion within the Process-container Environment is where individual Process- 
container Transaction Instances are annotated with special element level meta-data that contains 
specific pemnissions for specific individuals and groups (roles). This enables features such as 
Permissions including Read, View, Create, Delete permissions. 
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Security 

The Process-container environment fully supports security adequate to providing the 
following functionality: Signatures, Encryption, and Authentication. Other aspects include an 
5 Extension Security Model, a Journal Security Model, a Binder Security Model, a JavaScript 
Security Model, an XCL Security Model, and a Process-container Interaction Security Model 
including Client side Authentication. 

Sessions 

1 0 The architecture to support execution and bacl<-end processing of Process-containers is 

illustrated in FIG. 47. 

E. PROCESS DESCRIPTIONS 

15 

The system discussed above, including the hardware components and the program, are 
useful to perform the methods of the invention. However, it should be understood that not ail of 
the above described components and program elements are necessary to perform any of the 
present invention's methods, in fact, in some embodiments, none of the above described system 

20 is required to practice the invention's methods. The system described above is an example of a 
system that would be useful In practicing the invention's methods. For example, the XCL model 
described above is useful, but it is not absolutely necessary to develop a Process-container in 
order to perfcmn the methods of the invention. 

Refening to FIG. 1 , the flow depicted by the dashed cirde represents a method 

25 embodiment of the present invention that may be performed on the server devices 106, 108 and 
the client devices 102. 104. it must be understood that the particular arrangement of elements in 
the FIG. 1 , as well as the order of exemplary steps of various methods discussed herein, is not 
meant to imply a fixed order, sequence, and/or timing to the steps; embodiments of the present 
invention can be practiced In any order, sequence, and/or timing that is practicable. 

30 in general terms and refemng the FIG. 1 , the method steps of the present invention can 

be summarized as follows. A client device 104 is used to define a process that Involves 
transactions with remote users. A representation of the process Is stored In a process-container 
along with any documents necessary to execute the transactions that mal^e up the process. The 
client device 104 transmits the process-container to a remote server device 106 that may include 

35 a database or other application. The remote server interacts with the process-container, 
modifying and/or updating the documents stored therein as necessary, and then sends the 
process-container on its way according to the process definition within the logic of the process- 
container. Eventually the client device 104 that initiated the process, receive the process- 
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container and is able to displaying the new contents of the process-container or otherwise 
interact with it. 

F. CONCLUSION 

5 It is clear from the foregoing discussion that the disclosed systems and methods of 

providing Process-container platforms represents an improvement in the art of process 
automation and collaboration. While the method and apparatus of the present invention has 
been described in tenns of Its presently preferred and alternate embodiments, those sldDed in the 
art will recognize that the present invention may be practiced with modification and atteratfon ' 

10 within the spirit and scope of the appended claims. The specifications and drawings are, 
accordingly, to be regarded In an niustrative rather than a restrictive sense. 

Further, even though only certain embodiments have been desalbed In detail, those 
having ordinary skill in the art will certainly appreciate and understand that many modifications, 
changes, and enhancements are possible without departing from the teachings thereof. All such 

1 5 modifications are intended to be encompassed within the following claims. 
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1 1. A method comprising: 

2 defining a process including at least one transaction; 

3 storing a representation of tiie at least one transaction in a process-contalnen 

4 transmitting the process-container to at least one remote entity; 

5 receiving the process-container from the at least one remote entity; and 

6 displaying contents of the process-container. 
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1 

1 2. A method comprising: 

2 defining a process Including at least one transaction; 

3 storing a representation of the at least one transaction In a process-container; 

4 transmitting the process-container to at least one remote entity; and 

5 updating the process-container on the at least one remote entity. 



1 3. The method of claim 2 further comprising: 

2 receiving the process-container from the at least one remote entity. 

1 4. The method of claim 2 further comprising: 

2 displaying contents of the process-container. 
3 
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1 

1 5. A method comprising: 

2 defining a process inciuding at least one transaction; 

3 storing the at least one transaction in a process-container; 

4 transmitting the process-container to at least one ren^ote entity; and 

5 interacting with the process-container on the at least one remote entity. 

1 6. The method of claim 5 further comprising: 

2 receiving the process-container from the at least one remote entity. 

1 7. The method ofclaim 5 further comprising: 

2 displaying the contents of the process^ntainer. 



3 
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1 

1 8. A process-container comprising: 

2 a logic module; 

3 a storage module communicatively coupled to the logic module; and 

4 an Interface module communicatively coupled to the logic module. 
5 
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1 

1 9. A process-container comprising: 

2 a logic module; 

3 a storage module in communication with the logic module; and 

4 an Interface module in communication with the logic module. 
5 
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1 

1 10. A processKX)ntainer comprising: 

2 a presentation module; 

3 a logic module coupled to the presentation module; and 

4 a data module coupled to the presentation module. 

1 11 . The process-container of claim 10 further comprising a journal module coupled to the 

2 presentation module. 

1 1 2. The process-container of claim 10 wherein the logic is coupled to the data module. 
2 
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1 

1 13. A process-container comprising: 

2 a data module; 

3 a logic module coupled to tlie data module; and 

4 a presentation module coupled to the data module. 

1 14. The process-container of claim 13 further comprising a journal module coupled to the data 

2 module. 

1 15. The process-container of claim 14 wherein the logic is coupled to the journal module. 
2 
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1 

1 16. A process-container comprising: 

2 at least one binder; 

3 at least one attachment coupled to the at least one binder; and 

4 at least one transaction coupled to the at least one binder. 

1 17. The process-container of claim 1 6 further comprising a journal coupled to the at least one 

2 binder. 

1 1 8. The process-container of claim 17 wherein the journal Includes at least one mutation. 

1 1 9. The process-container of claim 17 wherein the journal includes a plurality of mutations 

2 grouped into at least one cycle. 

1 20. The process-container of claim 16 further comprising an Identifier coupled to the at least one 

2 binder. 

1 21 . The process-container of claim 16 further comprising a shell annotation coupled to the at 

2 least one binder. 

1 22. The process^ntalner of daim 16 wherein the at least one binder includes at least one 

2 resource. 

1 23. The process-container of claim 22 wherein the at least one resource Includes at least one of 

2 an opaque resource, an object resource, a meta-data resource, and a data resource. 

1 24. The process-container of claim 22 wherein the at least one resource includes a virtual 

2 unifbnm resource locator (VURL). 

1 25. The processr^sontalner of cteim 16 wherein the at least one attachment includes at least one 

2 multipurpose internet mail extension (MIME) bytestream. 

1 26. The process-container of claim 25 wherein the at least one MIME bytestream includes at 

2 (east one application document. 

1 27. The process-container of claim 16 wherein the at least one attachment includes at least one 

2 appllcatfon document. 
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28. The process-container of daim 16 wherein the at least one transaction includes at least one 
resource. 

29. The process-container of dalm 28 wherein the at least one resource Includes at least one 
extensible markup language (XML) document 

30. The process-container of daim 29 wherein the at least one XML document is compliant to an 
external document type definition (DTD). 

31 . The process^ontalner of daim 16 wherein the at least one transaction Indudes at least one 
data processing instruction. 

32. The process-container of daim 16 wherein the process-container is operable to be executed 
on a peer. 

33. The process-container of daim 16 wherein the process-container is operable to be 
transmitted between a plurality of peers. 



-101- 



wo 02/05106 



PCT/USOl/21462 



1 

1 34. A peer Ibr executing a process-container comprising: 

2 a runtime support environment incfuding 

3 an engine wherein the engine includes at least one of means for object mapping, 

4 means for persistence, means for joumaiing, means for querying, means for schema validation, 

5 means for compounding documents, and means for synchronizing documents. 
6 
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1 

1 35. A peer for executing a process-container comprising: 



2 a runtime support environment including 

3 an engine; 

4 an extension application program interfiace (API) coupled to the engine; and 

5 at least one process-container extension coupled to the extension API. 



1 36. The peer of claim 35 wherein the at least one process-container extension includes at least 

2 one of a gateway extension, a worlcflow extension, a rules extension, a protocol extension, and a 

3 transport extension. 

1 37. The peer of claim 35 wherein the virtual mabhine includes a Java virtual machine. 

1 38. The peer of claim 35 wherein the engine Includes 



2 a support module; 

3 a runtime module coupled to the support module; 

4 a core module coupled to the runtime module; and 

5 a process-container module coupled to the core module. 



1 39. The peer of claim 38 wherein the engine further includes at least one API. 

1 40. The peer of daim 39 wherein the at least one API includes at least one of an extension API, 

2 a JavaScript API , and a XML component language (XCL) API. 

1 41. The peer of daim 38 wherein the support module includes at least one of an interpreter 

2 package, a language parser package, a extensible stylesheet language transformation (XSLT) 

3 processor, a XML path language processor (XPATH), a serviet package, a naming interface 

4 package, a directory interface package, a message service package, a mall package, and an 

5 activation fifamewori^ package. 

1 42. The peer of daim 38 wherein the runtime module Indudes at least one of a persistent store 

2 subsystem, a process-container session subsystem, a verb protocol subsystem, a process- 

3 container event interface, a process-container packet interface, a process-container attachment 

4 interface, a process-container email interface, a process-container message interface, and a 

5 process-container service interface. 

1 43. The peer of daim 38 wherein the core module Includes at least one of means for object 

2 mapping, means for persistence, means for joumallng, means for querying , means for schema 

3 validation, means for compounding documents, and means for synchronizing documents. 
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1 44- The peer of daim 38 wherein the process-container module includes at least one process- 

2 container. 

1 45. The peer of claim 38 wherein the process-container module includes at least one of a binder, 

2 an attachment, a transaction, and a journal. 
3 
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1 

1 46. A system for automating a process comprising: 

2 at least one process-container; and 

3 at least one peer; 

4 wherein the at least one process-container includes data and Instructions relevant to a 

5 process and wherein the at least one peer is operable to execute the instructions, transmit the 

6 process-container, and receive the process-container. 

1 47. The system of claim 46 wherein the at least one process-containe/- is mobile. 

1 48. The system of claim 46 wherein the at least one process-container is self-contained. 

1 49. The system of claim 48 wherein the at least one process-container is self-contained wherein 

2 the peer Is operable to execute the process-container without reference to other resources. 

1 50. The system of claim 48 wherein the at least one process-container is self-contained wherein 

2 the peer is operable to execute the process-container off-line. 

1 51 . The system of claim 46 wherein the at least one process-container is asynchronous. 

1 52. The system of claim 46 wherein the at least one process-container is executable. 

1 53. The system of claim 46 wherein the at least one process-container is visualizable. 

1 54. The system of claim 53 wherein the at least one process-container is visualizable as a web 

2 site. 

1 55. The system of claim 46 wherein the at least one process-container is an agent. 

1 56. The system of claim 46 wherein the at least one process-container is operable to provide a 

2 communication Wnk to a peer on a remote system. 
3 
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1 

1 57. A device, comprising: 

2 a processor; and 

3 a storage device coupled to said processor and storing instructions adapted to be 

4 executed by said processor to: 

5 define a process including at least one transaction; 

6 store a representation of the at least one transaction In a process-container; 

7 transmit the process-container to at least one ren)ote entity; 

8 receive the process-container from the at least one remote entity; and 

9 display contents of the process-container. 

1 58. A medium storing Instructions adapted to be executed by a processor to perform a method 

2 of collaborating, said method comprising: 

3 defining a process including at least one transaction; 

4 storing a representation of the at least one transaction in a process-container; 

5 transmitting the process-container to at least one remote entity; 

6 receiving the process-container from the at least one remote entity; and 

7 displaying contents of the process-container. 

1 59. A medium transmitting instructions adapted to be executed by a processor to perform a 

2 method of collaborating, said method comprising: 

3 defining a process including at least one transaction; 

4 storing a representation of the at least one transaction in a process-container; 
6 transmitting the process-container to at least one remote entity; 

6 receiving the process-container from the at least one remote entity; and 

7 displaying contents of ttie process-container. 
8 
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1 

1 60. A computer-readable medium that stores program code and data accessible by and 

2 executable by a processor in a data processing system, the program code and data Including: 

3 a first module operable to define a process including at least one transaction; 

4 a second module operable to store a representation of the at least one transaction in a 

5 processHSontainer; 

6 a third module operable to transmit the process-container to at least one remote entity; 

7 a fourth module operable to receive the process-container from the at least one remote 

8 entity; and 

9 a fifth module operable to display contents of the process-container. 

1 61. A system for collaborating comprising: 

2 means for defining a process including at least one transaction; 

3 means for storing a representation of the at least one transaction in a process-container; 

4 means for transmitting the process-container to at least one remote entity; 

5 means for receiving the process-container from the at least one remote entity; and 

6 means for displaying contents of the process-container. 

1 62. A system for process automation comprising: 

2 means for defining a process including at least one tast^; 

3 means for storing a representation of the at least one task In a process-container; 

4 means for transmitting the process-container to at least one remote entity; 

5 means for perfonning the at least one task on the at least one remote entity; and 

6 means for updating the process-container based on performance of the at least one task. 

1 63. The system of claim 62 further comprising: 

2 means for receiving the process-container from the at least one remote entity; and 

3 means for displaying contents of the process-container. 
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